3 ms·

I disagree for a number of simple reasons. - Cost. You now require every domain owner to also pay for certificates (or get a free one, but the process is rough

I disagree for a number of simple reasons. - Cost. You now require every domain owner to also pay for certificates (or get a free one, but the process is roughly the same). - Limited choices. The keys to the kingdom are owned by a few corporate interests. - Encrypted browsing is simply unnecessary for certain classes of sites (non-logon, informational sites). - It increases the barrier for entry to put a basic website up. As well as knowing some html and css, you also need to know about certificates and keys, how to deploy them, and how to keep them safe. - Internal network communication becomes a lot harder with self-signed certificates. You've now got to generate certs and add them to trust stores. Leave the choice to the site operators and the users. Fix the CA system before forcing it upon everyone. I have HAProxy set up as the SSL termination point. It fronts about 15 different applications. But there's no easy way to decrypt at the proxy and then re-encrypt to the backend servers. We're not ready for mandatory SSL.

bkeroack 12y ago
> Cost The certificate issue is a browser problem. Self-issued certificates are trivial to produce, and in the era of mandatory TLS they probably should not produce the huge scary browser warnings we see today. I'm not a UI expert, but I could envision a "medium severity" browser warning that states the connection is encrypted but the certificate can't be verified. I don't see the logic behind abandoning encryption entirely rather than tolerate some level of self-signed certificates. > Limited choices. Arguably the whole CA system is in need of serious reform. This is orthogonal to HTTP/2 and TLS. > Encrypted browsing is simply unnecessary for certain classes of sites (non-logon, informational sites). I could not disagree more. Encryption is--from an efficiency standpoint--literally just some bit-twiddling (after key exchange). The efficiency cost is trivial, the social benefits are enormous. It's very much worth it. > It increases the barrier for entry to put a basic website up. This is one advantage of baking it into the protocol. If the HTTP/2 implementation takes care of the details of encryption (including certificate generation if necessary), website authors don't need to be concerned with it. Everything will just work. > Internal network communication becomes a lot harder with self-signed certificates. As stated above, certificates are not barriers. If your network is "trusted", then why would you care if the certificates are self-signed? You are arguing instead to not use encryption at all! Do you see how backward this is?
- akerl_ 12y ago
  Your local network may be trusted, but self-issued certificates are effectively worthless to regular internet users, because they make MITM attacks trivial. This is the reason they have huge scary warnings. Encryption without authentication and trust defeats passive snooping but does absolutely nothing to protect against MITM, which is a real and prevalent threat. Setting HTTP/2 to encrypt everything but removing the big warnings that appear when trusted authenticity cannot be established would be a net security downgrade, because the lay user will trust their connection when they ought not.
  - lmm 12y ago
    > Encryption without authentication and trust defeats passive snooping but does absolutely nothing to protect against MITM, which is a real and prevalent threat. Sure. But non-encryption leaves you vulnerable to both passive snooping and MITM. > Setting HTTP/2 to encrypt everything but removing the big warnings that appear when trusted authenticity cannot be established would be a net security downgrade, because the lay user will trust their connection when they ought not. How about only showing the padlock for certificated sites, and requiring a certificate when a secure request is made (http2s:// ?), but allowing encryption with a self-signed certificate for "insecure" URLs (http2://) and just not showing the padlock?
    - bkeroack 12y ago
      Exactly. An analogy is with password salting: you don't salt passwords because it makes the hashes unbreakable, you do it to increase the amount of work attackers have to do to successfully recover the passwords. Even without verified certificates, mandatory TLS would require a MITM attacker to be present at the time of the connection (not passively record traffic and attack later) for every connection they wanted to snoop on. For a stateless protocol like HTTP, that's a massive amount of work to do if you want to snoop on any large scale. The increase in work required is probably even greater (relatively) than the increase achieved in the example of password salting (which is considered a security no-brainer)!
- jsmeaton 12y ago
rakoo 12y ago
You're conflating TLS and the current CA model. I'm all for TLS-everywhere and ditching the CA model (no, there are no easy alternative to the model we have come to build and accept, it will have to be gradually evicted) Here's how the security warnings are in current browsers: - HTTP: no warning - untrusted HTTPS: warning - trusted HTTPS: no warning This is dumb. We explicitely say that an untrusted HTTPS is worse than raw HTTP, even though it preserves more privacy at a very little cost. We should alternate the two first levels.

bkeroack 12y ago

> Cost The certificate issue is a browser problem. Self-issued certificates are trivial to produce, and in the era of mandatory TLS they probably should not produce the huge scary browser warnings we see today. I'm not a UI expert, but I could envision a "medium severity" browser warning that states the connection is encrypted but the certificate can't be verified. I don't see the logic behind abandoning encryption entirely rather than tolerate some level of self-signed certificates. > Limited choices. Arguably the whole CA system is in need of serious reform. This is orthogonal to HTTP/2 and TLS. > Encrypted browsing is simply unnecessary for certain classes of sites (non-logon, informational sites). I could not disagree more. Encryption is--from an efficiency standpoint--literally just some bit-twiddling (after key exchange). The efficiency cost is trivial, the social benefits are enormous. It's very much worth it. > It increases the barrier for entry to put a basic website up. This is one advantage of baking it into the protocol. If the HTTP/2 implementation takes care of the details of encryption (including certificate generation if necessary), website authors don't need to be concerned with it. Everything will just work. > Internal network communication becomes a lot harder with self-signed certificates. As stated above, certificates are not barriers. If your network is "trusted", then why would you care if the certificates are self-signed? You are arguing instead to not use encryption at all! Do you see how backward this is?

akerl_ 12y ago
Your local network may be trusted, but self-issued certificates are effectively worthless to regular internet users, because they make MITM attacks trivial. This is the reason they have huge scary warnings. Encryption without authentication and trust defeats passive snooping but does absolutely nothing to protect against MITM, which is a real and prevalent threat. Setting HTTP/2 to encrypt everything but removing the big warnings that appear when trusted authenticity cannot be established would be a net security downgrade, because the lay user will trust their connection when they ought not.
- lmm 12y ago
  > Encryption without authentication and trust defeats passive snooping but does absolutely nothing to protect against MITM, which is a real and prevalent threat. Sure. But non-encryption leaves you vulnerable to both passive snooping and MITM. > Setting HTTP/2 to encrypt everything but removing the big warnings that appear when trusted authenticity cannot be established would be a net security downgrade, because the lay user will trust their connection when they ought not. How about only showing the padlock for certificated sites, and requiring a certificate when a secure request is made (http2s:// ?), but allowing encryption with a self-signed certificate for "insecure" URLs (http2://) and just not showing the padlock?
  - bkeroack 12y ago
    Exactly. An analogy is with password salting: you don't salt passwords because it makes the hashes unbreakable, you do it to increase the amount of work attackers have to do to successfully recover the passwords. Even without verified certificates, mandatory TLS would require a MITM attacker to be present at the time of the connection (not passively record traffic and attack later) for every connection they wanted to snoop on. For a stateless protocol like HTTP, that's a massive amount of work to do if you want to snoop on any large scale. The increase in work required is probably even greater (relatively) than the increase achieved in the example of password salting (which is considered a security no-brainer)!
jsmeaton 12y ago

rakoo 12y ago

You're conflating TLS and the current CA model. I'm all for TLS-everywhere and ditching the CA model (no, there are no easy alternative to the model we have come to build and accept, it will have to be gradually evicted) Here's how the security warnings are in current browsers: - HTTP: no warning - untrusted HTTPS: warning - trusted HTTPS: no warning This is dumb. We explicitely say that an untrusted HTTPS is worse than raw HTTP, even though it preserves more privacy at a very little cost. We should alternate the two first levels.