Interestingly, for users who are running the Superfish software there's no need for a MitM to have the private certificate as the Superfish MitM proxy is validating any cert. I have a screenshot here: http://defaultstore.com/four.png of it validating my MitM proxy cert. To be clear, I'm in the middle of the TLS connection from Bank of America thanks to Superfish not denying the bogus cert I provided.
If you have Superfish and want to validate this behavior for yourself, you can visit https://defaultstore.com/ and watch it accept an expired cert. Given this situation the Chrome team and others should without a doubt treat the cert as revoked.
It's likely a lot of people are still running that software. I bought a Lenovo Yoga 2 11 today and it had Superfish installed by default and all my connections are MitM'd on that machine.
UPDATE: if the cert is revoked, it will likely leave a lot of people unable to browse the web. It would be nice if the revocation process in Chrome could provide users with instructions on how to remove the software.
>To be clear - we will still define how to use HTTP/2.0 with http:// URIs, because in some use cases, an implementer may make an informed choice to use the protocol without encryption. However, for the common case -- browsing the open Web -- you'll need to use https:// URIs and if you want to use the newest version of HTTP.
Someone explain to me when "an informed choice" would ever come to the conclusion of, "Encryption? Not Necessary!"
> Someone explain to me when "an informed choice" would ever come to the conclusion of, "Encryption? Not Necessary!"
I've been informed that encrypted web traffic costs money for the certificate and for additional server hardware. Thus I made the informed choice to use HTTP/2.0 without encryption.
>encrypted web traffic costs money for the certificate and for additional server hardware
1.) You can make and self sign your own cert. As another poster pointed out, there's also distributed solutions.
2.) When we let standards that are going to be in-place for at least a decade be manipulated by the hardware costs at their inception, it's a bad standard.
Unencrypted HTTP/2 is for host-internal communication, ie. between app servers and public endpoints. Firefox and Chrome are both only going to support HTTPS for HTTP/2.
90% of the time the desirable quality of TLS traffic is authentication of the server, not encryption. Encryption only really comes handy when confidential information and authentication credentials get exchanged.
Now if you provide authentication by other means, and confidentiality of the traffic not important, plain text protocols make sense because it enables caching proxy.
Typical use case: software updates distributed as signed packages. The information isn't very confidential, and using plain HTTP enables the usage of a caching local proxy.
> 90% of the time the desirable quality of TLS traffic is authentication of the server, not encryption.
Authentication of the server is not sufficient, you also have to authenticate every message as having a valid checksum and signature.
>Typical use case: software updates distributed as signed packages
This is a specific use-case because the package checksums are verified before any of the code is executed (unlike injected javascript to webpages). Also the checksum is usually obtained from the package server, so if SSL is broken the checksum can be spoofed as well.
> Do you perhaps mean "cryptography" rather than "encryption"?
That's true the poster said authentication of the server, if you sign every message cryptographically, you'll be able to detect message tampering. I should edit that.
>Encryption only really comes handy when confidential information and authentication credentials get exchanged.
It's 2015 and we have quad-core processors in phones that are faster than my laptop. What reason can anyone possibly have to not at least strive to encrypt everything? When is it advantageous to not encrypt?
