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.
[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.
[code]
400 The plain HTTP request was sent to HTTPS port
400 Bad Request
The plain HTTP request was sent to HTTPS port
cloudflare-nginx
[/code]
Fixed by adding me.Secure = true to the Connected event.
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
[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.
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.
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.