I recently had a problem uploading pdf’s to a server. This app has been working for over a year. The administrator replied :
The issue is that Xojo does not support modern HTTPS encryption protocols. Based on recent security findings in the news, deprecated security protocols were recommended to be phased out. These should not be used in any production systems, so they were removed (and a change control message was not properly sent out – my bad). I’ve re-enabled SSLv3, and confirmed the application works as expected.
I did notice that I had forgotten to set secure mode (blush).
Can anyone comment on the correctness of the admin’s reply - I’m out of my depth there.
I had a similar problem, my app just stopped working.
The default “Connection Type” for the XOJO HTTPSecureSocket is 2. Changing that to 3 solved the issue. Unfortunately I received no warning from the service I was connecting too it changed the requirements, which sounds exactly like what happed to you. It was only through lots of experimentation I found the issue.
There also seems to be a bug in the IDE in Windows. When you change the Super of the TCPSocket from a HTTPSocket to SSLSocket it does not update the inspector properties to reflect the new parameters; Conenction Type, Secure, Certificate, etc… You have to save the project, click off the TCPSocket, click something else then reclick the TCP socket again.
I too need to understand this more. It seems some services allow you to use their certificate and therefore you do not need to specify a certificate of your own. I need a primer on how this works…
Yeah, thanks for the link for context. I just didn’t want anyone have the impression that a Xojo TLSv1 connection type was somehow vulnerable to Poodle- it is not.
The BEAST attack you mention is completely different from POODLE. It not only requires a man in the middle but typically also a cross domain attack to exploit. But to be clear, Xojo is not vulnerable to a BEAST attack either (with TLSv1) because it uses the empty TLS record mitigation before sending the message- which renders that attack ineffective.
Stay tuned to the upcoming version of Xojo if you are interested in TLSv1.1/v1.2- but the current version is not vulnerable to either BEAST or POODLE when using TLSv1.
[quote=143224:@Travis Hill]The BEAST attack you mention is completely different from POODLE. It not only requires a man in the middle but typically also a cross domain attack to exploit. But to be clear, Xojo is not vulnerable to a BEAST attack either (with TLSv1) because it uses the empty TLS record mitigation before sending the message- which renders that attack ineffective.
Stay tuned to the upcoming version of Xojo if you are interested in TLSv1.1/v1.2- but the current version is not vulnerable to either BEAST or POODLE when using TLSv1.[/quote]
Good to hear, and good to see someone with security knowledge
I’m freaked out when it comes to these kinds of security issues, and don’t like seeing customers of any product get “bit”. Sorry about that mistake!
Regarding the matrix in the article and where it displays the protocol and browser and its related vulnerability. How does that relate to say a Xojo Desktop App talking to an SSL PHP page?
The exploits discussed focus on how they relate to browsers but I am curious if these are still an issue if the site (or PHP page) it connects to is specifically designed to only work with a desktop app? For example, If a PHP page is viewed in a browser it simply returns nothing because the PHP page is set up with a specific protocol to talk to the App. The PHP page will simply ignore anything that is not secure or not coming from the APP.
If you’re using an HTTPSecureSocket to communicate with the PHP page, then the security layer is invisible. All you have to do is set the socket’s ConnectionType to TLSv1.
Will there be any situation whee setting it to TLSv1.2 would when setting it to TLSv1.1 or TLSv1?
Basically what I’ asking is if there is a downside to using the most recent version of TLS… I would naively assume TLSv1.2 would be backward compatible with TLSv1.1 and TLSv1… Is that correct?
We don’t add additional fallback capabilities over what OpenSSL provides.
OpenSSL states that IF you want the best compatibility you SHOULD use the SSLV23 mechanism (which seems bizarre to me) and A TLS/SSL connection established with these methods may understand the SSLv2, SSLv3, TLSv1, TLSv1.1 and TLSv1.2 protocols.
It doesn’t say there what the order is that it tries.
It does further say that, for TLSv1.1 A TLS/SSL connection established with these methods will only understand the TLSv1.1 protocol
It’s says something similar for TLSv1 and I presume TLSV1.2 would be similar but can’t find anything that specifically says so.