I don't know why parent is getting downvoted: he is correct, we need to https all the things to improve https for everyone.

The nerdy tinfoilhat who can't even be bothered to setup his browser to use https when possible..

spacefight is right. Offering HTTP along with HTTPS is an antipattern. As an example, I give you Reddit, where HTTP and HTTPS services are identical. That means you can log in on the HTTPS site, and I can have your session cookie or even your password.

The only sane solution is to set up HTTP to redirect to HTTPS, and add an HSTS cookie.

Not necessarily.

Allowing access on both http and https is indeed a bad practice, but not in regards to the scenario you described.

The scenario you described has been covered since long by the 'secure' attribute, available when creating cookies. Assuming the authentication was performed from within the https channel, the cookie won't be disclosed when requests are triggered on the http channel. This covers the 'Reddit' case from an application layer perspective.

The vulnerability is rather in browsers (such as Firefox). They allow the rewriting of an existing cookie value through the http channel, although it was originally set through the https channel. This is a huge problem and I still don't understand why this isn't reported by any researcher as a critical security flaw...

In either case it leaks information. Even if I can't get your session key, I can see every URL you visit, and every field you put in. Also, if your login form can be served over HTTP (or any included script is, which thankfully Chrome now disallows when the page loads over HTTPS), I can just get your password. Guess how Reddit serves their login form? Yup, it's right on http://www.reddit.com/.

You are right, all your Reddit traffic should be encrypted, but the reason is not because it's a vulnerability, it's because you have a personal expectation of privacy, which is different from an unexpected or undesired incident in their information system.

Let's not forget that from Reddit's point of view, the browsing of the public content is not confidential, hence no need to hide it. Only your credentials are confidential, hence their transmission is configured to happen through a secure channel by default (if you're lucky). As long as it matches their security policy, it is not a vulnerability, per say. The vulnerability here is that Reddit 1) accepts authentication events sent through HTTP and that 2) Reddit keeps considering accounts as reliable after a successful HTTP authentication. We could also argue on the quite insignificant consequences of your Reddit account being hacked (for most users) in opposition to the disclosure of a password that you have not used anywhere else (isn't it?).

As a user, you believe that the Reddit pages you browse should be private, which led you to conclude Reddit is flawed. I agree that Reddit users' traffic should be kept private. But, we are still in an era where information security is defined by the expectations of corporations, not those of customers/users. The total cost induced by the fact that anyone on the same network as you can see your Reddit traffic remains lower than improving the security of the platform.

If you want Reddit to consider this as a "vulnerability", you need to either convince lots of users to stop using Reddit until they fix this (traffic volume pressure) or convince loud people to start shaming their owners on large audience news sites (shame pressure). These two strategies are the only ones that work, to my knowledge. As long as their business keeps running and there is no shamming, they don't have any real incentive to pull the source code and fix this: it's not a major security vulnerability. (the fact that browsers overwrite https cookies from http responses is a major one, though...)

I consider them vulnerable. As a test I successfully hijacked a Reddit identity using nothing but tcpdump on my router. Leaking credential information is a form of vulnerability. Just because lots of people do this does not make it less vulnerable.

Even if Reddit allowed you to log in via HTTPS only and kept your session cookie secure, but let you browse anonymously over HTTP, they'd still be leaking info about what you are browsing, as you said. I agree, this is a problem for the user. Say, the user is looking at topics about maternity leave while her boss doesn't know she is pregnant. What can the boss do with this info? Or say the user is looking into methadone clinic experiences at work?

Browsing over HTTP also lets an attacker inject content. Ads are the obvious and somewhat innocuous case, but think about the phishing opportunities here. "Please log in to proceed" with a form that submits the password to the attacker.

You are right they won't change until either their users start complaining, or something really bad happens as a result of this negligence, but I am simply using them as an example of a pretty widespread issue. Lots of sites do this and it's very unfortunate.

Honestly I'd just prefer the HTTP endpoint not even exist.

The only reason why some sites still use http is because of the need to purchase an ssl certificate from one of the cartelized CA providers.

How about ad fill rates? I'm not directly involved in add ops myself, but I've heard that now, even in 2015, major web properties still see a roughly 60% drop in ad revenue on HTTPS. Thats a big deal for an advertising supported website. (Though obviously not so much a big deal for a website like this selling an Ubuntu cell phone).

Yeah, it's the primary reason why I can't get any of our properties on https. Any ad supported platform / website simply can't afford to use https.

It's not just that. TLS setup is additional effort.

Let me walk you through it:

    $ openssl genrsa -out $server.key 2048
    $ openssl req -new -sha256 -key $server.key -out $server.csr

Get the CSR to a CA and get the cert in your email inbox. Compose the cert into a chain (the most painful part of the process).

Put the cert and the key in /etc/ssl/certs/example.com.crt and respectively /etc/ssl/private/example.com.key;

In your nginx config add the following:

    server {
    
    listen 443 ssl spdy;
    server_name www.example.com
    
    ssl on;
    ssl_session_timeout 5m;
    ssl_session_cache shared:SSL:5m;
    
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
    ssl_prefer_server_ciphers on;
    
    # HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
    add_header Strict-Transport-Security max-age=15768000;
    
    resolver 8.8.8.8;
    
    ssl_certificate /etc/ssl/certs/example.com.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;
    
    #...
    }

Restart nginx. If you want to only do HTTPS, and have HTTP redirect to HTTPS:

    server {
        listen 80 default_server;
        server_name _;
        rewrite ^ https://www.example.com$request_uri permanent;
    }

It took 3 minutes to write this comment. Getting a new cert up and running will take you $5 and 15 minutes if you follow these instructions. Free if you use startssl.com. Cheapest wildcard I found was https://www.ssls.com/ when they ran a sale: $42. Current cheapest Google turned up was https://cheapsslsecurity.com/sslproducts/wildcardssl.html for $60. Personally, I prefer wildcard certs whenever possible, free certs from startssl.com.

Why should we pay more? Same product available at cheaper price $60 for 1 year as well alphassl wildcard at $42. https://www.ssl2buy.com/cheap-wildcard-ssl-certificates-ads

Sure, it's easy if you know the steps. But it's still additional effort.

All web servers just do HTTP by default.

Setting up passwords is additional effort. Just leave them blank. To me that doesn't seem like an excuse to subject your users to what HTTP entails, and to subject yourself to the liability it implies.

It's not an excuse, but it is the reason why.

That, and shared hosts.

True, and how stupid is that? We consider a self signed certificate to be worse than no encryption.

It's because they are. How many times will this be brought up? The browser has no way of knowing whether gmail.com should be serving a self-signed cert (pinning notwithstanding), so it must treat a self-signed cert as a MITM attack at all times. Try to think through how else it could possibly work, and you'll see why the browsers do this.

No, they are not.

The browser should treat any HTTP connection as a MITM attack at all times, too. Actually, it should also treat it as multiple MITM because everyone in your network or in the path can see your traffic.

We could argue if it even makes sense to differentiate between SSL with self-signed certs and plain HTTP connections when warning users, I'll give you that. But in no way SSL with self-signed are worse than HTTP.

> Try to think through how else it could possibly work, and you'll see why the browsers do this.

Funny :)

And all of the other customers are left unprotected.

This is the responsibility of the admin, not the user.

I agree, but as a user you don't have any control over that. Https Everywhere is a solution to the immediate problem.

Wouldn't using a VPN help if you're that concerned?

VPNs aren't secure end-to-end. You can still have your connection spied upon and/or hijacked in the link between the VPN gateway and the website servers (including by the VPN operators themselves!).

What about PIA? The client has encryption and they come highly recommended from various people.

Sure the client has encryption (most VPN clients do), but that's just up to their servers. From the PIA servers to the final web server, there's no extra protection, so if you're accessing an HTTP service, it's unencrypted.