I just have one question on this, since things were update (thank you, by the way):
Is there any validation on the certificate itself? For example, if I owned www.mysite.com and purchased a certificate for that domain, the prior sslSocket before this release… you couldn’t verify that the certificate was actually FOR that specific domain. This meant that I could use a self-signed or other certificate for a site, and it would appear to be a secured connection as far as the sslSocket was concerned.
Going a step further, it would be awesome if you could put a ‘certificate’ property included with the sslSocket and be able to grab issuer, domain, expiration, etc. data from it… something like:
certIssuer = sslSocket.certificateIssuer
This, at the least, would let me be able to handle myself if the certificate didn’t match the domain I was going to or was expired.
The new framework Xojo Net sockets (available now on iOS) have a ValidateCertificates property that allows you to turn certificate validation on or off. That functionality will arrive on the other platforms as we move more of the new framework to more platforms. That’s already in the works.
If you would still want the ability to read individual certificate properties, please file a feature request- I’m not aware of one right now.
Appreciate the feedback, but this means the SSL support in Xojo on the other platforms should still be considered at risk and not secured.
One change to note is apparently now HTTPSecureSocket’s default connection property for me.Secure is now false.
Strange. Easy to fix, but strange.
[quote=150012:@Tim Parnell]One change to note is apparently now HTTPSecureSocket’s default connection property for me.Secure is now false.
Strange. Easy to fix, but strange.[/quote]
Where are you seeing this ?
We set it to true in the constructor so I’m wondering about this ?
[quote=150036:@Norman Palardy]Where are you seeing this ?
We set it to true in the constructor so I’m wondering about this ?[/quote]
This relates to my other post about connection issues, I was able to get around the HTTP 1.0/1.1 issue by changing to HTTPSecureSocket.
A 2014r2.1 build could connect successfully, a 2014r3 build would get a HTTP error 400 (Bad Request). Details below.
400 The plain HTTP request was sent to HTTPS port
400 Bad Request
The plain HTTP request was sent to HTTPS port
Fixed by adding
me.Secure = true to the Connected event.
Secure hasn’t changed from true to false / false to true in any recent version so I’m not sure this is necessarily related
I made no other changes and 2014r3 will get a 400 response unless I explicitly set secure to true.
(yes, I set ConnectionType to TLSv1 in r2.1)
It’s not at all related to the original post, I just thought that it should be noted in the topic titled changes.
secure hasn’t changed defaults though
its the same as its been for several years
just peeked in 2012r2.1 and they all come out the same from there forward
so i’m not sure why setting it secure would affect your connection that way but its not changed from what it ever was
You do realize that this is too late right? When the Connected event fires, you have already connected insecurely.
Just out of curiosity, is this a socket created in code? or was it dragged onto a layout?
[quote=150084:@Greg O’Lone]You do realize that this is too late right? When the Connected event fires, you have already connected insecurely.
Just out of curiosity, is this a socket created in code? or was it dragged onto a layout?[/quote]
That’s what I thought, but it works somehow. It’s a dragged socket.
Make sure you haven’t unchecked the Secure box in the inspector, then.
I would have never thought of something so basic.
It was originally a HTTPSocket, then I changed it to HTTPSecureSocket, and I never even noticed there was a switch. Alas it was switched off.
Why would there even…
It’s there because you can use it for both secure and insecure connections depending on your needs. Otherwise you’d need two sets of code.
… but why is it an IDE switch that defaults to off?
This has more to do with how the control was created than anything else. The fact that you have to drag out another object and then change the superclass is what’s causing the problem here. The Secure property was not present in the HTTPSocket, so when it was converted the value is set to the default for the type… Which with a Boolean, the default value is False.