HTTPS encryption

General
1

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.

Thanks

2

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…

3

We’ve updated the default to TLSv1 for the next release.

4

Wow. Upgrading to a insecure TLS. Let’s hope TC isn’t handling encrypted traffic because TLSv1 is vulnerable to POODLE, a man-in-the middle attack.

TLSv1 was also released in… drumroll 1999.

Sad for a company that touts security.

5

TLSv1 is NOT vulnerable to Poodle- only SSL is. Please don’t spread misinformation.

6

for more information.

7

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.

8

no problem. anyone in the security arena knew it was an SSLv3 issue and not TLS* issue.

9

And more info:

SSL POODLE

10

Wrong exploit.

There is an exploit for TSL 1.0, but it isn’t POOLE. It does do what I described.

https://www.kb.cert.org/vuls/id/864643

[quote]"A vulnerability in the specification of the SSL 3.0 and TLS 1.0 protocols could allow an attacker to decrypt encrypted traffic.
"[/quote]

11

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.

12

[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 :slight_smile:

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!

13

To sum up this conversation, so the casual reader won’t freak out:

  1. Because of recently revealed security exploits, you will need to start changing the ConnectionType of your sockets to use TLSv1.
  2. TLSv1 is going to be the default in the next release, but you should still set it for backwards compatibility. See #1.
  3. For anyone who needs it (and it will depend on who you are connecting to), TLSv1.1 and TLSv1.2 will be available soon as well.
14

Also, it might be worth reminding folks that the numbering scheme is confusing : TSLv1 is more recent than SSLv3. See http://en.wikipedia.org/wiki/Transport_Layer_Security

15

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.

Thoughts?

16

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.

17

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?

  • karen
18

I don’t believe that our plugin provides automatic fallback for TLS connections.

20

that would be a feedback request if it doesn’t…

21

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.