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.
Related
I have to support an Android device that uses Android API <20 (KitKat and older). We use AWS for our APIs and want to support TLSv1.3 and beyond, but these devices may not be upgraded for some time. Android API <20 doesn't natively support TLSv1.3+, but is it possible to use a third-party TLS library to support TLSv1.3? If so, how? Googling around has not turned up anything apart from "upgrade your device".
It's possible to do this using the Conscrypt Library which goes all the way back to Android 2.x
You can reference that library and then make use of it by:
Security.insertProviderAt(Conscrypt.newProvider(), 1);
I don't think Android device will support TLS 1.3 because TLS 1.3 is too new and almost all the browser cannot support TLS 1.3. The most of theme they use the older version TLS 1.2, TLS 1.2 compatible with all the IDE and Web platforms such as chrome or firefox. Also TLS 1.3 is very hard to create because there is almost no info about encryption with TLS 1.3.
In my project fetch request with https is not working for Android<5.0. I know it's for ssl certificate issue. But I don't know how to add or solve that problem. So far I tried many things by googling the problem.
Any help or suggestion will be appreciated.
Thanks.
There is no solid solution to this issue. I had the same issue and I have tried it and it still doesn't work in old samsung devices. The android devices which are equal and below 5.0 use TLS 1.1 or 1.0. The new standard TLS is 1.2. Even tho TLS 1.2 exists in Android devices below 5.0 they are not enabled by default. So you have to enable it manually by changing socket so when your app loads it should enable TLS 1.2 in old devices. The certificate of Android<5.0 devices has been issued before TLS 1.2 introduced. Below are useful links so good luck with trying it.
Android 4.1 to 4.4 KitKat - Enable TLS 1.2 for API
https://github.com/facebook/react-native/issues/7192
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.
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.
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