I need to connect a WinCE6.0 device to a web based server using HTTPS.
The problem: WinCE6.0 uses WinInet v6 which supports SSL2, SSL3 and TSL1.0 None of which are supported in the current (2018) best practices due to their security flaws.
I doubt I can drop in a newer version of WinInet and expect it to run.
I had thoughts of porting CURL to WinCE.
I'm thinking this issue has already been addressed by the CE community, but I'm not seeing an available solution.
How can I get an old embedded device to securely connect to the WWW?
From GuruCE:
If you want to use TLS 1.1 and 1.2 on CE a suitable solution is to use mbedTLS library from ARM. It has a BSD-like license, so not too restrictive. Only one change to the makefiles is needed to get it to work on CE.
Related
I was testing our equipment TCP performance using iperf3, WiFi, powerline and ethernet. Do I need use the same version in both client and server so that I won't see weird issue or performance drop?
Current I'm using
server: iperf 3.1.3
client: iperf 3.0.11
Thanks
For the most part you can use different versions of iperf3 between the client and server. Clearly they'll only be able to use features / functionality that the client and server have in common.
There were some old "beta" versions of iperf3 that weren't compatible with later versions, but everything since the official 3.0 release should interoperate with everything else. If not, I'd consider that a bug.
I inherited a Cast Iron appliance which reports that it is version 5.0.1.5 - several years old and off support.
This is mostly used to talk to Salesforce, who just sent us an email saying they are turning off SSL 3.0 in a few weeks. POODLE.
Can anybody tell me if this version of Cast Iron supports TLS and will continue to work when SFDC disables SSL 3.0? Or point me to something that tells me how to check this myself? I'm drawing a blank with Google..
Better upgrade fast.. this broke a client instance..
http://www-01.ibm.com/support/docview.wss?uid=swg21687945
To answer my own question: yes, old Cast Iron version 5.0.1 does support TLS 1.0.
Salesforce shut SSL 3.0 off this past weekend on all their sandbox instances and our CI integrations are still happy.
Castiron version below 6.1.0.12 do not support TLS. Once salesforce switched off ssl in sandboxes our orchs (all 150) of them would not connect to salesforce.
We are upgrading to version 7.
I need to implement a server running on Windows CE 5.0 that shall communicate on a secure connection. To implement a secure connection SSL looks like a good choice.
The Windows CE 5.0 Winsock implementation allows to implement all the SLL stuff using the Winsock Secure Sockets. But the problem is that the referred site states:
SSL does not support the following Winsock functionality ... "Calls to the accept function".
How can I implement a SSL secured server when accept will not work? What other options do I have to implement a secure connection to a Windows CE 5.0 device?
Edit: My current application implementation is in C++. So I would prefer an approach that use the Windows API or a C++ library.
We ported the Mentalis Secure Socket Library to the Compact Framework for when we needed SSL. It was fairly painless, though not without its bugs.
MatrixSSL supports Windows CE:
MatrixSSL™ is an embedded SSL and TLS implementation designed for
small footprint applications and devices. Available is a fully
supported, commercial version as well as an open source version that
is available for download. MatrixSSL allows secure management of
remote devices. Several secure embedded Web servers also use MatrixSSL
for their encryption layer.
MatrixSSL has been ported to operating systems including
FreeRTOS, Bare Metal, eCos, VxWorks, uClinux, eCos, FreeRTOS, ThreadX,
WindowsCE, PocketPC, Palm, pSOS, SMX, BREW, MacOS X, Linux and
Windows.
I'm trying to test WS-MAN capabilities to manage multiple hypervisors (mainly ESXi and Hyper-V); in terms of Hyper-V, all samples I come across insist on first tuning the Hyper-V authentication to "basic"; does anyone know if this is a shortcoming in current OpenWSMAN implementation or by design it can't support other authentication mechanism OR please correct me if my understanding is wrong :-).
System Details:
Host OS: SL 6.1
OpenWSMAN: 2.2.0 (client version)
Thanks!
I found an explanation for above observation. On linux, OpenWSMAN uses OpenSSL for authentication connections, now OpenSSL on Linux supports "digest" and Windows machines does not. Windows supports Kerbos/GSSAPI which is not currently supported by OpenSSL.
Thanks!
What is the impact on existing code to migrate from WebSphere MQ V6 to V7?
Can we make simply the change?
Like all good questions, the answer here is "it depends."
First of all, don't go to v7.0, go to V7.1 at least, better yet to V7.5.
Using client or bindings mode connections? You can upgrade the QMgr without touching a client-based app in most cases. Any version of WMQ client can talk to any version of WMQ server, however its best not to leave apps on an unsupported version of WMQ client. Of course, the app running on the old client won't get the new function such as automatic reconnect or performance improvements, even though the QMgr is at V7.5.
Using SSL? The SSLPEER element order changed and the commands to manage certificates changed. Good news, cert management is now performed with runmq*km commands living in the {mq install}/bin directory so you don't need to hunt down the GSKit directory and figure out whether to use gsk6*, gsk7* or gsk8* commands.
If you go from 32 to 64 bit, you may need to recompile programs or exits.
Correct settings for PATH, CLASSPATH and LIBPATH change across versions.
There's much more and it's well covered in the Infoceenter. Each Infocenter has a section on migration. Within that section, there's subsections by version and within those there are subsections by platform. Pick the target version of WMQ (that's V7.5, right? Say yes!) and and drill down. Start here:
Migration from V6.0 to V7.5
Migration from V6.0 to V7.1
Migration from V6.0 to V7.0