HTTPS encryption

@Norman Palardy why are you sleeping? its 3am EST, so it has to be late whatever timezone you are in. I know why I am up and it isn’t by choice. Its hard to sleep with cracked ribs.

But then again you are a machine about helping people at all hours.

Let me hop in and clarify since I’ve been in the weeds in this area. :slight_smile:

Our TLS (v1.0/v1.1/v1.2) support won’t automatically fall back to versions prior than the one you specify- and that’s intentional- since someone explicitly asking for a newer version of TLS should get that. It is certainly technically possible for us to add a separate ConnectionType that would fallback to particular TLS versions but it is not our current plan to do so- since you will be more secure going forward by explicitly using the highest version compatible with the services you need to communicate with.

Why I was asking…

If service provider unexpectedly updates what version if TLS they support in the future, I don’t want my app to break. I assume they might go up a version # or two of TLS.

I don’t know what the differences between TLS versions are, and I would prefer not to have to be concerned about it!

  • Karen

Since POODLE, many more service providers have enabled newer versions of TLS and you’ll likely find you can select the highest version they support and be fine for quite a long time going forward. I doubt it will be much of an issue in practice for you.

[quote=143572:@Karen Atkocius]Why I was asking…

If service provider unexpectedly updates what version if TLS they support in the future, I don’t want my app to break. I assume they might go up a version # or two of TLS.

I don’t know what the differences between TLS versions are, and I would prefer not to have to be concerned about it!

  • Karen[/quote]

I think the proper way to handle this, and Travis or someone from XOJO can chime in if I am steering you in the wrong direction, would be to start with the highest level of security that Xojo supports. In this case TLSv1. Then in your app you handle the downgrade if your service supports something lower and will not connect at the more secure level. For example;

Try to connect at TLSv1 - unsuccessful connection,
Try again at SSLv3 - success.

When Xojo upgrades their TLS to version 1.1 and 1.2 you would add those at the top and try to use those first, only downgrading if your service rejects your connection.

The only issue with this is if the industry adopts a higher level of security than Xojo’s sockets will support and won’t allow a connection otherwise, in which case it would break a lot of Xojo developed apps.

[quote]@Joseph Evert
Try to connect at TLSv1 - unsuccessful connection,
Try again at SSLv3 - success.
[/quote]

That has been the default methodology for years, however,
it is also how a POODLE attack (which exploits SSLv3) starts.
It tries to force a downgrade from secure protocol to a vulnerable one.

Hello Guys, i just post here so that i dont`t open another conversation.

I recently tested HTTPSSocket and it seems that i cannot make it to work, same code but instead of https i nave http it works perfectly, on https on the other hand it gives me all kind of strange errors that i cannot find the right solution for them , i did put the tls on the encryption , and on the example i just do a post to a form and thats it .

i use something like that :

dim StatusSock As New HTTPSocket

StatusSock.Secure = True
StatusSock.ConnectionType = SSLSocket.TLSv1

StatusSock.SetFormData(d)
rstat = StatusSock.Post(“https://test_link”, 30)

and as far as i remember i was getting 102 error until i quit using the https and i took my chances with http, but it would be preferable to get back on https.

Easy : http://documentation.xojo.com/index.php/HTTPSecureSocket

Keep in mind that the success of an https connection also depends on the server you are connecting to. If, for instance, the server does not support TLS, it won’t work. That said, most web servers today do support TLS.

The 102 error code is for a socket disconnect. There are a few other things I can think of off the top of my head…

  • The server to which you are connecting doesn’t allow HTTP/1.0. Most servers don’t have a problem with this, but I’ve seen a few newer API servers which are beginning to ignore older clients.
  • the server doesn’t support HTTPS at all
  • the server may require http authentication for an https connection.

Hello Greg,

Well the server is setup by me , it might be a problem on the HTTP/1.0 part, i will have a look once i finish the current project, in the meantime it will stay like that, by default was set to accept only https connections and i had to disable that setting in order to be able to post the data.

It might be a problem that the certificate is self generated ? and not the paid ones ? i doubt that but i take it as an option.

Thanks for the advice i will let you know what was the problem in case i find it .

Self-signed certificates should not be a problem.