55 ms·

I'm not surprised, this does simplify things in many ways, and to be honest, there isn't a good reason not to use SSL anyway in many cases. What we need next i

I'm not surprised, this does simplify things in many ways, and to be honest, there isn't a good reason not to use SSL anyway in many cases. What we need next is a browser happy way to use HTTPS only for encryption and not for verification (yes, I know!), but it would make this migration much easier. This would reduce the reliance on CAs, and would make SSL certs free in many cases.

pedrocr 13y ago
What we need is to do away with CAs entirely and use the DNS hierarchy to distribute keys (with DNSSEC for example). That way you only have to trust your own registrar (that you already need to trust anyway) and not any random CA in the world. So if you own example.com you get the COM registrar to sign your key and become your own CA for *.example.com.
- marshray 13y ago
  Seems like you could accomplish the same thing by CA pinning your site to Verisign (who runs the DNSSEC root).
  - pedrocr 13y ago
    That and an expensive *.example.com certificate would get you half of the way there. You still wouldn't be able to be your own CA, signing certificates for foo.example.com that other people can use. And it would require everyone to buy certificates from Verisign. Nowadays national governments already setup their own CAs because they want to be able to issue certificates for all sorts of government organizations. With the setup I'm suggesting Germany would get .de signed, then they could sign gov.de and then have gov.de sign someagency.gov.de. somecompany.de would get their certificate from the DE registrar when they sign up for the domain and also be able to issue somepartner.somecompany.de or jabber.somecomapny.de certificates that if discovered only compromise part of their network, unlike having a wildcard certificate installed on every server.
- joosters 13y ago
  Doesn't this just mean the registrar ends up (effectively) being the one who trusts all the random CAs instead?
  - pedrocr 13y ago
    What random CA's? All the registrar does is say "I the owner of COM have delegated EXAMPLE.COM to FOO both by pointing the address to their servers and signing their public key." After that example.com can delegate within its domain both the addressing (regular DNS) and the signing of certificates for subdomains.
thejosh 13y ago
reason: $$
toast0 13y ago
Good reasons not to use SSL: SSL has a significant number of required packet exchanges at startup, so latency for small objects is much larger; this is especially noticeable if there's a high round trip time between the client and server. SSL blocks proxy caching. The CA situation isn't great; especially if you're supporting older mobile clients, which basically never update their root certs. Debugging is harder (and HTTP/2 already gets complaints about that)
- acdha 13y ago
  > SSL has a significant number of required packet exchanges at startup This is improving, however – see e.g. http://www.igvita.com/2013/10/24/optimizing-tls-record-size-and-buffering-latency/ http://www.igvita.com/2013/10/24/optimizing-tls-record-size-... > SSL blocks proxy caching This is only true for involuntary transparent proxying, which is also a huge source of reliability problems. After seeing how many times JavaScript is broken or images are degraded by "helpful" ISPs I'm quite happy to change the model to something which requires the client to opt-in to enable a proxy.
  - toast0 13y ago
    > This is improving, however – see e.g. http://www.igvita.com/2013/10/24/optimizing-tls-record-size-and-buffering-latency/ http://www.igvita.com/2013/10/24/optimizing-tls-record-size-... That's interesting (and I'll try to apply it where i'm running SSL), but what I'm more worried about is the very beginning of the connection. http://chimera.labs.oreilly.com/books/1230000000545/ch04.html#TLS_HANDSHAKE http://chimera.labs.oreilly.com/books/1230000000545/ch04.htm... SSL adds two extra round trips, which doubles the latency of a small request. This is really unfortunate when you're in a high latency environment already.

pedrocr 13y ago

What we need is to do away with CAs entirely and use the DNS hierarchy to distribute keys (with DNSSEC for example). That way you only have to trust your own registrar (that you already need to trust anyway) and not any random CA in the world. So if you own example.com you get the COM registrar to sign your key and become your own CA for *.example.com.

marshray 13y ago
Seems like you could accomplish the same thing by CA pinning your site to Verisign (who runs the DNSSEC root).
- pedrocr 13y ago
  That and an expensive *.example.com certificate would get you half of the way there. You still wouldn't be able to be your own CA, signing certificates for foo.example.com that other people can use. And it would require everyone to buy certificates from Verisign. Nowadays national governments already setup their own CAs because they want to be able to issue certificates for all sorts of government organizations. With the setup I'm suggesting Germany would get .de signed, then they could sign gov.de and then have gov.de sign someagency.gov.de. somecompany.de would get their certificate from the DE registrar when they sign up for the domain and also be able to issue somepartner.somecompany.de or jabber.somecomapny.de certificates that if discovered only compromise part of their network, unlike having a wildcard certificate installed on every server.
joosters 13y ago
Doesn't this just mean the registrar ends up (effectively) being the one who trusts all the random CAs instead?
- pedrocr 13y ago
  What random CA's? All the registrar does is say "I the owner of COM have delegated EXAMPLE.COM to FOO both by pointing the address to their servers and signing their public key." After that example.com can delegate within its domain both the addressing (regular DNS) and the signing of certificates for subdomains.

thejosh 13y ago

reason: $$

toast0 13y ago

Good reasons not to use SSL: SSL has a significant number of required packet exchanges at startup, so latency for small objects is much larger; this is especially noticeable if there's a high round trip time between the client and server. SSL blocks proxy caching. The CA situation isn't great; especially if you're supporting older mobile clients, which basically never update their root certs. Debugging is harder (and HTTP/2 already gets complaints about that)

acdha 13y ago
> SSL has a significant number of required packet exchanges at startup This is improving, however – see e.g. http://www.igvita.com/2013/10/24/optimizing-tls-record-size-and-buffering-latency/ http://www.igvita.com/2013/10/24/optimizing-tls-record-size-... > SSL blocks proxy caching This is only true for involuntary transparent proxying, which is also a huge source of reliability problems. After seeing how many times JavaScript is broken or images are degraded by "helpful" ISPs I'm quite happy to change the model to something which requires the client to opt-in to enable a proxy.
- toast0 13y ago
  > This is improving, however – see e.g. http://www.igvita.com/2013/10/24/optimizing-tls-record-size-and-buffering-latency/ http://www.igvita.com/2013/10/24/optimizing-tls-record-size-... That's interesting (and I'll try to apply it where i'm running SSL), but what I'm more worried about is the very beginning of the connection. http://chimera.labs.oreilly.com/books/1230000000545/ch04.html#TLS_HANDSHAKE http://chimera.labs.oreilly.com/books/1230000000545/ch04.htm... SSL adds two extra round trips, which doubles the latency of a small request. This is really unfortunate when you're in a high latency environment already.