We need to make certs free and deprecate HTTP in favour of HTTPS with AES/TLS

[AHSauge]

Summary of this thread: Why is anything on the Internet in cleartext anymore?

Which is a flawed question. What you should be asking yourself is what does people gain by encrypting non-sensitive information? Why should people and companies use money and resources to remove the use of unencrypted HTTP for transmitting such information? Why should a newspaper article be transmitted encrypted? Why should Google encrypt the transmission when someone want to read their documentation of the Android API? In my opinion there are no reasons to justify it. You're not gaining anything but disadvantages.

Encryption makes sense when your transmitting something worth protecting like a password or some other personal information, not when you're reading about an API or the latest news. It's quite obvious really, or so I though?

[BlackStar]

Which is a flawed question. What you should be asking yourself is what does people gain by encrypting non-sensitive information? Why should people and companies use money and resources to remove the use of unencrypted HTTP for transmitting such information? Why should a newspaper article be transmitted encrypted? Why should Google encrypt the transmission when someone want to read their documentation of the Android API? In my opinion there are no reasons to justify it. You're not gaining anything but disadvantages.

What disadvantages are you talking about?

The advantage is obvious: privacy from any and all middlemen (do you really wish your ISP to know what newspapers you read, what stuff you buy and what porn sites you visit?)

The disadvantage is increased latency in the initial connection due to the handshake.

Which do you value more: your privacy or a 10ms delay on your first visit to a site?

[locovaca]

Last time I checked, I didn't have to get my SSH host keys from a host key authority.

No, you're supposed to carry around or memorize the Host Key for the system you are connecting to, or for a public system, publicize what the key is supposed to be. Are you suggesting that the HTTP infrastructure undertake a similar tactic? If so, that would be insane and unmanageable.

[AHSauge]

What disadvantages are you talking about?

In addition to latency as you mention, there is also no possibility to do caching anywhere between the client and the server. There is also the matter of encryption using more resources than not doing so, and your users can't have a somewhat older browser like Firefox 2 or IE6 if your site is relying on named-based virtual hosting, aka. there are multiple domains on the same IP. Your user experience may also be degraded because the browser is not caching HTTPS-sites the same way they do HTTP-sites.

The advantage is obvious: privacy from any and all middlemen (do you really wish your ISP to know what newspapers you read, what stuff you buy and what porn sites you visit?)

Yeah, big freakin' deal. So someone may hypothetically be able to see what I'm doing, so what? I'm not doing anything illegal, and besides, the ISP and anyone else able to listen in, can easily see that I've been connected to both the newspaper and the porn site even though the content is encrypted. You see, both destination and source is still plain text, making it all somewhat obvious what you're doing. You don't accidentally stumble unto a porn site when you make several follow up requests download dozens MB from it

Oh, and what stuff I buy should already be encrypted as I would most likely need to provide debit or credit card information to actually buy it. Combine that with the fact that I also probably need to log in or register, and you've got yourself some good, strong reasons to encrypt.

The disadvantage is increased latency in the initial connection due to the handshake.

Which do you value more: your privacy or a 10ms delay on your first visit to a site?

I value people not wasting resources on paranoia and unnecessarity. If HTTP is to be completely deprecated, it will require time and money to deprecate it and to keep it that way (i.e permanent increased requirements for server hardware). That is money that either you and I as end users have to pay one way or the other, or the site owner (provided he/she/it never charges for it in any way). In the long run, the end user will be paying for that, not site owners, and for what? So that some paranoid people may have the illusion that no one can see what they are doing?

Oh, and by the way: If you really want to value your privacy, you should start with blocking out Google and Facebook completely. The can and do most likely track your movements on the Internet. Facebook can even connect your movements to your actual name, email, friends etc. Both of them can track you regardless of whether sites are using HTTP or HTTPS. All they need is to be included some form, for instance as Google Analytics and Facebook Like/Connect. That is an actual privacy issue.

[RealNC]

No, you're supposed to carry around or memorize the Host Key for the system you are connecting to, or for a public system, publicize what the key is supposed to be. Are you suggesting that the HTTP infrastructure undertake a similar tactic? If so, that would be insane and unmanageable.

I'm not suggesting that, of course. What I'm suggesting is allowing people to use encryption without requiring a certificate from a self-declared "trusted" third party. The browser in this case should not inform the user that the site is "authenticated", "safe", or whatever. Because it isn't. The fact that the site uses encryption should not even be visible to the user (not actively hidden either, just not advertised with any special message or icon.)

Maybe I'm unable to explain my point properly :-/ Am I the only one to whom the above makes sense?

[Ex-Cyber]

Why would you need to know if the encryption key is genuine? The only one who needs to know is me. And, naturally, I do know, since I created it.

If I want to encrypt a message to you and have the encryption mean anything, I need to know that I have your encryption key, and not merely a key claiming to be yours (potentially generated by a MITM -- perhaps a hostile or compromised ISP or a phishing-style spoofer -- who has the real key and can re-encrypt and forward the message to you, so that neither of us suspects anything is wrong). That doesn't necessarily mean that I need to know your real-world identity or trust a central authority, just that we both agree on some token of identity that cannot be faked by an untrusted third party.

[RealNC]

My concern are passwords that are sent clear-text over the wire and can be sniffed. The only reason I ever needed encryption. I don't run the PayPal or the National Bank websites :-P The site the user connects to might be compromised, but I don't give any promise that it isn't. All I need is that the passwords users use to login to a forum or whatever can't be sniffed on their way to the site. And for just that, the browser shouldn't nag the user with "this site is unsafe!!!11" messages.

[BlackStar]

In addition to latency as you mention, there is also no possibility to do caching anywhere between the client and the server.

Your user experience may also be degraded because the browser is not caching HTTPS-sites the same way they do HTTP-sites.

These are technical issues that are solvable.

There is also the matter of encryption using more resources than not doing so, and your users can't have a somewhat older browser like Firefox 2 or IE6 if your site is relying on named-based virtual hosting, aka. there are multiple domains on the same IP.

No IE6 support? Bring it on, I say!

Yeah, big freakin' deal. So someone may hypothetically be able to see what I'm doing, so what? I'm not doing anything illegal, and besides, the ISP and anyone else able to listen in, can easily see that I've been connected to both the newspaper and the porn site even though the content is encrypted. You see, both destination and source is still plain text, making it all somewhat obvious what you're doing. You don't accidentally stumble unto a porn site when you make several follow up requests download dozens MB from it

Yes, the ISP will know you've visited youporn even with HTTPS - but do you really want it to know that you are visiting the goat porn section of that site?

Oh, and what stuff I buy should already be encrypted as I would most likely need to provide debit or credit card information to actually buy it. Combine that with the fact that I also probably need to log in or register, and you've got yourself some good, strong reasons to encrypt.

There is usually no encryption before you actually click the "buy now" button. The ISP and anyone in the middle knows exactly which items you've clicked, compared and bought - they can create a complete profile of your personality and preferences.

I value people not wasting resources on paranoia and unnecessarity. If HTTP is to be completely deprecated, it will require time and money to deprecate it and to keep it that way (i.e permanent increased requirements for server hardware). That is money that either you and I as end users have to pay one way or the other, or the site owner (provided he/she/it never charges for it in any way). In the long run, the end user will be paying for that, not site owners, and for what? So that some paranoid people may have the illusion that no one can see what they are doing?

Google moved most of their services to HTTPS and saw a ~10% increase in CPU load. This is a non-issue.

The real cost is the costs are the certificate (which is what this thread is all about) and the increased latency (which Google is already working to solve).

Oh, and by the way: If you really want to value your privacy, you should start with blocking out Google and Facebook completely. The can and do most likely track your movements on the Internet. Facebook can even connect your movements to your actual name, email, friends etc. Both of them can track you regardless of whether sites are using HTTP or HTTPS. All they need is to be included some form, for instance as Google Analytics and Facebook Like/Connect. That is an actual privacy issue.

Thanks for the concern but I already do that.

[locovaca]

I'm not suggesting that, of course. What I'm suggesting is allowing people to use encryption without requiring a certificate from a self-declared "trusted" third party. The browser in this case should not inform the user that the site is "authenticated", "safe", or whatever. Because it isn't. The fact that the site uses encryption should not even be visible to the user (not actively hidden either, just not advertised with any special message or icon.)

Maybe I'm unable to explain my point properly :-/ Am I the only one to whom the above makes sense?

I understand what you're saying now. Some Verisign "staff members" might be breaking in your doors anytime now.

[baryluk]

Tls-srp

I'm still waiting for major adoption of TLS-SRP. It negotatates keys without needing any kind of certificates. I was reading about this protocol few years ago, and was always wondering why Firefox isn't implementing it. AFAIK this was because of some patents, but now they are not valid any more and AFAIK FIrefox and Chromium is going to have TLS-SRP support soon. (some enterprise products like Cisco equipment, or some comercial SSH applications already have SRP implemented). TLS-SRP was standarized in RFC about 5 years ago, but only GNUTLS have patches for it (which fortunetly can be used with apache), but no webbrowser. Hope this will soon change.

PS. Of course TLS-SRP do not resolve everything, but it will secure communications to things like social networking sites, web mail accounts, forums, private wikis, time mangaments, bugzillas, etc. etc. everywhere where you need to log-in to authenticate and view something and perform some actions. It isn't unfortunetly useful at all for anonymously accessible informations - for such still certificates will be needed.