4 ms·

Great decision! When Google started to work on SPDY and made it SSL-only, we saw what the future could be: people upgrade to the new protocol for performance, b

by ivanr 13y ago

Great decision! When Google started to work on SPDY and made it SSL-only, we saw what the future could be: people upgrade to the new protocol for performance, but get better security too. What's not to like! I was really afraid that the standardisation of HTTP/2.0 will break this, but now all seems well after all. But this is not enough; we also need to work on opportunistic encryption, to be used for sites that do not use SSL today, without any certificates, in a completely transparent fashion that requires no end-user configuration. Such encryption would not be enough to defeat active main in the middle attacks, but it would defeat passive monitoring of non-encrypted communication. To those complaining about the hassle of SSL: The biggest problem today is the fact that virtual SSL hosting (multiple sites sharing an IP address without sharing the certificate, otherwise known as Server Name Indication, or SNI) is not feasible. As soon as Windows XP (the only major platform that does not support SNI) goes away, SSL will become much easier; especially for hosted services. That the cost (of certificates) is a problem is a myth. It might have been a problem in the past, but today there are so many CAs to choose from. There are CAs that give away free domain-validated certificates. There are CAs that give away free certificates to open source projects. And there are also companies that sell certificates for a couple of dollars only. Obtaining certificates is, no doubt, a hassle, but the fact remains that CA-issued certificates is the only practical option to deploy a secure web site today. There are also some issues with latency, but perhaps with HTTP/2.0 (and some possible improvements in TLS 1.3) those are going to be minimised, too.

caf 13y ago
It is worth noting that Windows XP is EOL April 8, 2014.
fulafel 13y ago
> But this is not enough; we also need to work on opportunistic encryption, to be used for sites that do not use SSL today, without any certificates That's exactly what this proposes!
- ivanr 13y ago
  No, not as far as I can tell. The linked document has two options for opportunistic encryption, one of which is without server authentication, but that does not mean without certificates. The draft http://tools.ietf.org/html/draft-nottingham-http2-encryption-01 http://tools.ietf.org/html/draft-nottingham-http2-encryption... also states that the certificates would be used, just not necessarily checked. My issue with the use of certificates is that it would in practice probably mean required manual server-side configuration, which would be a barrier to adoption (even if self-signed certificates are allowed). I would prefer a certificate-less approach that is available by default and for all sites. The proposal also requires HTTP/2.0 for opportunistic encryption, even though we could probably make it work with HTTP/1.x too.
  - fulafel 13y ago
    Well, ignored certs would be functionally near-equivalent to no certs. If implmentations ended up keeping some meaning for them, you could look at how most ssh server keys are generated - no configuration.
therealunreal 13y ago
Can you really trust the CAs? There have been many cases where a CA was compromised or tricked into signing fraudulent certs, never mind government mandated back doors.
- ivanr 13y ago
  It's all matter of risk assessment, which will depend on what your security requirements. Trust that they won't issue an interception certificate when a government agency asks them (with a warrant)? No. But, if you choose a well-established CA, I believe that the risk of fraudulent certificate is small enough to be accepted. Besides, how many cases of fraudulent certificates have been there? Very few actually, relatively speaking, when measured against millions of issued certificates every year. The current arrangements where CAs are able to issue certificates for arbitrary sites without owners' consent is clearly unsatisfactory. Hopefully we'll get key pinning abilities one day to improve the situation. At the end of the day, security is hard. The arrangement with public CAs is flawed, but we don't yet have a better solution that scales. For small (close) groups, a private CA with manual user pinning should work well enough, when deployed with HTTP Strict Transport Security.

by ivanr 13y ago

caf 13y ago

It is worth noting that Windows XP is EOL April 8, 2014.

fulafel 13y ago

> But this is not enough; we also need to work on opportunistic encryption, to be used for sites that do not use SSL today, without any certificates That's exactly what this proposes!

ivanr 13y ago
No, not as far as I can tell. The linked document has two options for opportunistic encryption, one of which is without server authentication, but that does not mean without certificates. The draft http://tools.ietf.org/html/draft-nottingham-http2-encryption-01 http://tools.ietf.org/html/draft-nottingham-http2-encryption... also states that the certificates would be used, just not necessarily checked. My issue with the use of certificates is that it would in practice probably mean required manual server-side configuration, which would be a barrier to adoption (even if self-signed certificates are allowed). I would prefer a certificate-less approach that is available by default and for all sites. The proposal also requires HTTP/2.0 for opportunistic encryption, even though we could probably make it work with HTTP/1.x too.
- fulafel 13y ago
  Well, ignored certs would be functionally near-equivalent to no certs. If implmentations ended up keeping some meaning for them, you could look at how most ssh server keys are generated - no configuration.

therealunreal 13y ago

Can you really trust the CAs? There have been many cases where a CA was compromised or tricked into signing fraudulent certs, never mind government mandated back doors.

ivanr 13y ago
It's all matter of risk assessment, which will depend on what your security requirements. Trust that they won't issue an interception certificate when a government agency asks them (with a warrant)? No. But, if you choose a well-established CA, I believe that the risk of fraudulent certificate is small enough to be accepted. Besides, how many cases of fraudulent certificates have been there? Very few actually, relatively speaking, when measured against millions of issued certificates every year. The current arrangements where CAs are able to issue certificates for arbitrary sites without owners' consent is clearly unsatisfactory. Hopefully we'll get key pinning abilities one day to improve the situation. At the end of the day, security is hard. The arrangement with public CAs is flawed, but we don't yet have a better solution that scales. For small (close) groups, a private CA with manual user pinning should work well enough, when deployed with HTTP Strict Transport Security.