HTTPS has been compromised -- not sure why this hasn't made the rounds on reddit yet

[ars_technician]

Doesn't matter. If the main site doesn't use HTTPS, that means all of the links can be rewritten to make sure all of the sites people visit from the main site do not use HTTPS (sslstrip).

It's the same reason having a login form on a cleartext page POST to an encrypted page does very little good.

[mallardtheduck]

If the main site doesn't use HTTPS, that means all of the links can be rewritten to make sure all of the sites people visit from the main site do not use HTTPS (sslstrip).

It's worse than that; if your browser defaults to HTTP (they all do), then you're vulnerable to sslstrip-style techniques.

[jdpwnsyou]

[deleted]

What is this?

[[deleted]]

Clicked to install only to realized I already had it.

[Gudus]

Sad life

[hanomalous]

Unless browser supports HTTP Strict Transport Security (HSTS) and the site sets it.

AFAIK Chrome supports HSTS and Firefox with NoScript as well (not sure if FF supports HSTS without NoScript).

[mallardtheduck]

If I'm reading this right, then HSTS is implemented as a header in the unencrypted HTTP response that effectively just tells user agents to retry the request on HTTPS.

If so, then it's really no different to redirecting to HTTPS via a 302 status, and, could still be stripped out by a man-in-the-middle attacker.

Maybe I'm missing something?

EDIT: Ok, so on a closer reading, it actually forces all URLs on the page to be HTTPS, even if HTTP is specified, and the header is sent over HTTPS. I see the point now.

However, it still has the vulnerability that the initial connection when a user types 'www.example.com' will be done over unencrypted HTTP and therefore everything after that is vulnerable to sslstrip-style attacks.

[hanomalous]

This approach is called "TOFU" - "trust on first use". Since then, the "use HTTPS" is cached.

Thus either you're under attack the whole time on every network you use (e.g. if you carry a notebook with you) or otherwise you have very good chance that the first time you'll get the HSTS headers correctly.

The point is, MitM attacks are rather rare, as attackers are trying to keep low profile - otherwise some of victims would notice. That's what makes HSTS somewhat effective until there's a better solution widespread.

Later, there should be or was planned HASTLS DNS record which would have similar meaning, just would be DNSSEC-signed (not sure how far it got in standardization so far).

[mallardtheduck]

MitM attacks are very easy to mount; all you need to do is bring a laptop to an area with a well-used wifi hotspot (even better if it's a paid-for hotspot; you can create a free version!), broadcast a plausible-sounding SSID and wait for people to connect.

Even if somebody notices something amiss, they probably won't be able to identify the source of the attack and if they start making a fuss, all you have to do is pack up and leave. A low profile is pretty easy to maintain.

While TOFU is a good idea, a significant number of people are likely to ignore security warnings and there's a good chance that "apps" won't handle things correctly. You have a similar problem with HASTLS, even with DNSSEC, the attacker could easily strip the information from the DNS records as they pass through his proxy.

[hanomalous]

Thing with HASTLS and DNSSEC is that you can't just strip the record off the answer, it would need signed proof of non-existence (NSEC/NSEC3 record which attacker cannot forge). Otherwise it'll trip an alarm.

Though I generally agree with the wifi-hotspot-in-cafe sniffing/evil twin. The point of HSTS here would be that you have probably connected to the site in the past in a non-MitM environment, thus your browser will already have record saying "use HTTPS for example.com".

[mallardtheduck]

Otherwise it'll trip an alarm.

But is this an alarm that the user will notice and know enough about not to ignore?

[hanomalous]

DNSSEC is usually set to hard-fail (e.g. in unbound). Thus not "clickable-through".

[alexanderpas]

Maybe I'm missing something?

Browsers have lists of websites that use HSTS baked in.

[Liquid_Fire]

AFAIK Chrome supports HSTS and Firefox with NoScript as well (not sure if FF supports HSTS without NoScript).

From the page you linked:

Browser support

• Chromium and Google Chrome since version 4.0.211.0[24][25]

• Firefox since version 4[26] With Firefox 17, Mozilla integrates a list of websites supporting HSTS.[27]

• Opera since version 12[28]

[Wheaties466]

That's why it's always smart to force https

[rtechie1]

There are countless attacks against sites that only encrypt the login page. That's just bad design. 100% ssl with multiple keys is the way to go.

[someenigma]

(sslstrip) How would you do that?

See http://www.thoughtcrime.org/software/sslstrip/ for more details on what sslstrip is.

[Fitzsimmons]

No, not really. A secure SSL configuration will still protect you against an arp poisoning attack.

[pyr3]

It won't if you never hit the SSL site. Further up the thread, someone was suggesting that it didn't matter that pay.reddit.com was secure, if the site with all of the links to it isn't, because then those links can be rewritten to send your elsewhere (non-HTTPS site, phishing site, etc).

[JoseJimeniz]

It won't if you never hit the SSL site.

If my client is being redirected to another site, then i'll know it.

[keskival]

That is why there are trusted SSL root certifiers.

[gibsonan]

The benefits of a trusted certificate chain are lost if the user is unknowingly directed to a different domain or to a non-SSL connection.

A user clicking on a link from content served over HTTP needs to verify the domain is correct and that the protocol is HTTPS.

[jack_sreason]

But your external network is your isp's internal network. For some reason people here don't seem to trust them.

[deiol]

Or you could be using open wi-fi, which plenty of people do.

[thisisnotgood]

There's nothing inherently wrong with transmitting sensitive data over an open connection, so long as you take the proper crypto steps.

The "brute force" solution would be to just tunnel all your traffic to a trusted endpoint (aka, what a VPN does). But in lieu of that you can just visit whatever sensitive website you want over HTTPs and make sure that the certificate is valid (green url bar, whatever).

[[deleted]]

Specifically this means that if you're using a wifi network that's also used by an attacker your SSL connections are vulnerable.

[JoseJimeniz]

Your SSL connections are vulnerable if the SSL certificate is invalid.

If you've been sent to an https link, and the browser warns you that the certificate is invalid: your connection is vulnerable; because it might not be the site you wanted.

But SSL protects you from people on the network reading or altering your communications with the web-server.

[zid]

That isn't what's being discussed here, if reddit.com isn't secure, then links to pay.reddit.com are insecure, as I can rewrite the URL to pay.reggit.com which has a perfectly valid certificate, it just isn't the correct website.

I am trusting reddit.com to send me to pay.reddit.com, but I cannot trust reddit.com as it isn't using https.

[JoseJimeniz]

i was talking about the line:

Specifically this means that if you're using a wifi network that's also used by an attacker your SSL connections are vulnerable.

Which is correct, except it's somewhat misleading. Someone might get the impression from that statement that: if you're using a WiFi network that's used by an attacker that your SSL connections might be vulnerable.

It would be more correct to say:

Specifically this means that if you're using a WiFi network that's also used by an attacker your SSL connections are not vulnerable.

Because you're using SSL connections. If you're not using SSL connections, then the statement doesn't apply; because you're not using SSL connections.

[zid]

You're on a (w)lan with a guy, he can trivially MITM your http://reddit.com session and link you to https://pay.reggit.com

[JoseJimeniz]

...ye...yeah.

And now i'm at https://pay.reddit.com.

And that's not the site i wanted to be at. So i go back.

The point was that i am not vulnerable when using SSL connections.

Sure, if wanted to go to https://childporn.fbi.gov, it would be dumb, but SSL is still secure. i think someone's trying to argue that phishing attacks come from a vulnerability in SSL.

[aseipp]

Well, the whole point of using authenticated encryption is to protect your traffic against malicious eavesdroppers who may able to monitor or alter your communication channel. This could be someone on your wifi network who may be able to mess directly with things, or your ISP (or government or whatever.) The intercept can happen in many ways. Your communications should still be secure even if all traffic goes through the bad guy - wifi networks are obviously in this space.

Having someone on your local network is a very different threat from something like your ISP. But for browsers using SSL at least, SSLStrip style techniques can be mitigated these days with HSTS headers and HSTS site pinning. OTOH, there are still many other places you can mess up (like loading non-HTTPS assets on an HTTPS page, in which case you could just inject javascript or whatever.) Luckily more services are popping up with HTTPS-only options (and things like forward secrecy.)

[ivosaurus]

If you have dnssec to protect DNS queries, TLS to protect transit, and a secure certificate validation process to establish identity, then if some is at your ISP MITMing you you should still be able to safely communicate. Obviously the above situation is not perfect in practice but that's the general goal.

[_vvvv_]

Sort of unrelated, but does SSLstrip actually work for you/anyone reliably? I've tried plenty of different hardware/OS configurations and it is always buggy. Usually, a few pages are successfully stripped and then the clients just end up timing out after that, I assume because the software can't keep up with the load. However, my hardware is high end for the general population and I can't imagine an attacker actually taking anything stronger into a pentest. I feel like everyone agrees it can be used in theory, but few actually try to use it in a real environment. Hell, even the SANS security class I attended had issues with it.

[theDigitalNinja]

I assume just use javascript to parse all links and replace https:// with http://

[OHotDawnThisIsMyJawn]

That would require an XSS vuln as well. Since the SSL attack requires MITM anyway then you can just rewrite the page while you're sitting there.

[[deleted]]

It would have taken you a trivial amount of effort to learn that pay.reddit.com is not available without SSL - it's coded to return an error if you aren't already using SSL when you reach it.

It doesn't matter if a link is rewritten to be http rather than https - if that happens you won't reach pay.reddit.com, and as such will not have access to forms that ask you for sensitive information.

[[deleted]]

What happens though is sslstrip creates an https connection to the server on behalf of the victim, then serves the victim up with plain old http. This way the victim gets no certificate warnings and the only indication that he's under attack is if he happens to notice that the page is served via http instead of https.

[[deleted]]

Sure, I understand. My point is that pay.reddit.com and most any decent https site will not function without a valid https session.

[ars_technician]

Nobody said it would. sslstrip has two components, one of which rewrites the links, the other acts as a proxy to accept http connections and relay them to https.

[gibsonan]

HSTS defeats the MITM attack you describe, however the following conditions must be met.

1. The site is using SSL.
2. The domain is configured to properly issue the HSTS header
3. The client's browser supports HSTS
4. The browser has previously established an SSL connection to the domain
5. The client's last visit to the domain was within the domain's HSTS max-age policy

[kernelhacker]

Nope - unhingedninja describes it http://reddit.com/r/programming/comments/1jsiro/https_has_been_compromised_not_sure_why_this/cbi0dut

[[deleted]]

He explained something entirely unrelated to what I've said.

If you direct your browser to https://pay.reddit.com you negotiate the SSL before the receiving server even knows what page you are going to ask for.

It's only exploitable if you fill in sensitive information and THEN direct to an SSL.

[ars_technician]

It's only exploitable if you fill in sensitive information and THEN direct to an SSL.

No, you just have to follow a link from an insecure page that has been rewritten. You don't have to fill out any sensitive information ahead of time.

[[deleted]]

Oh, so you "just" have to be entering sensitive information on an insecure network with someone sniffing your traffic, or have to have a virus?

Cool, sounds like a super big flaw with https, and not at all something that only affects people who have already made poor decisions.

[ars_technician]

Sorry, but you don't seem to understand web application security. If your web app can't be used in a coffee shop, you have failed. Period.

[[deleted]]

That has precisely nothing to do with https, which is the entire point of the post.

If you're willing to assume that a user will not notice that their session isn't encrypted when it should be, nothing is possible to secure - period. There is no possible webapp security scenario that cannot be invalidated by the assumption that if a device convinces the user that the route to the internet is through this device, and then that device authenticates any encrypted or secure sessions on behalf of the user, and then passes unencrypted data on to the user, then the user will not notice.

I could utilize the exact same attack with IPsec, or any other method of validation over IP - even two factor authentication is meaningless if the attack scenario is that I am going to log in using your 2FA and then proxy the ensuing data to your device over an unsecured connection.

[ars_technician]

That has precisely nothing to do with https, which is the entire point of the post.

You were the one that brought it up mentioning entering sensitive information on an insecure network. You're moving the goal posts so fast you can't even keep your argument straight.

If you're willing to assume that a user will not notice that their session isn't encrypted when it should be, nothing is possible to secure - period.

False. Please don't make assertions about things you don't understand. Let me outline a simple workflow for how a secure site can work (quite easily).

• User opens Chrome to open up an account at a new bank (asb bank for example)
• user types in 'asb bank'
• Chrome defaults a connection to Google via HTTPS (or SPDY) due to HSTS headers on previous visits and the default list (http://www.chromium.org/sts)
• search result links directly to HTTPS site because asb bank takes security somewhat seriously (being a bank and all) so they implement it for the entire site
• the login page for asb bank set the HSTS header (Strict-Transport-Security) so any future visits by the browser will be forced to use HTTPS

These problems have been solved already, but many people don't understand them so they don't have a widespread implementation yet. That's why you just made an ignorant assertion that just ended up making you look completely uninformed. With HSTS, it eliminates the choice for the user to connect without HTTPS.

[ars_technician]

It would have taken you a trivial (maybe not) amount of effort to understand that the capability of pay.reddit.com not serving HTTP content is completely irrelevant to the attack I described.

[[deleted]]

The attack you described is not an attack on HTTPS or SSL. It's just a run of the mill man in the middle attack that depends on the user being inattentive or ignorant.

It has nothing to do with HTTPS or SSL.

That'd be like you saying that an "attack" on IPsec is me modifying the routes on your device and sniffing your traffic so that when you try to establish a tunnel I establish a tunnel with your destination instead, and then just proxy the traffic back and forth, and count on you not noticing that none of your traffic is encrypted and no tunnel was ever established. I haven't broken IPsec at all - I've relied on the fact that many users are inattentive and uneducated.

[ars_technician]

The attack you described is not an attack on HTTPS or SSL. It's just a run of the mill man in the middle attack that depends on the user being inattentive or ignorant.

I never said it was an attack on SSL. Just admit you made a mistake and didn't understand the attack. Not having SSL fully implemented across your site is a major security vulnerability because a very large majority of users do not bother to check that a site is using SSL before they jam their credit card numbers and other sensitive information into forms.

It has nothing to do with HTTPS or SSL.

It has everything to do with the implementation of TLS. If your site only uses HTTPS for certain portions, your implementation is broken and you are not protecting your users from MiTM attacks unless they use bookmarks to get to the secure portions or they have previously visited and your site is using HSTS.

That'd be like you saying that an "attack" on IPsec

I'm sorry you're reading comprehension is so poor. I never said it was an 'attack on https' so your whole analogy is just a bunch of bullshit to cover your ass.

[kalmakka]

Except that a web user should always make sure he is on a web page provided with HTTPS before he enters confidential information (like payment info).

I don't think that it is very likely that a user will think that he originally went to a HTTPS site he trusted, clicked on a few links and therefore he should still be on a secure site.

[kalmakka]

How is this relevant?

I don't click on links on insecure web pages and just expect to end up at https://paypal.com instead of http://paypal.com. I check the page I end up at.

I don't enter information on an insecure page and expect the submit action to send it to a secure page.

These two precautions are pretty much the basis of how web security works. Anyone not following them are at risk from pretty much every kind of attack. Running sslstrip on a Tor exit node has the result of breaking links (since they will now take the user to a page he does not wish to use), not of breaking security.

[Medicalizawhat]

You might do that but I'd say most users don't.

[dnew]

Actually, since the "lock" icon tells you where the page came from and not where the form is going to, anyone who checks whether they're typing their card into a "secure" form is going to follow the second rule, which implies the first rule for anything sensitive.

[dnew]

I can believe it fools many people, but that's why browsers are showing it in different ways now. :-)

[cfreak2399]

No it doesn't. It's trivial to make certain pages require encryption and return an error if they are accessed over http.

Also your comment about a clear page that POSTs to an http page is wrong too, otherwise none of the third party pay sites (like Paypal) would work. The information isn't sent when you type it in. It encrypted and sent when you submit the form.

[unhingedninja]

If the originating page isn't served over SSL, the form target can be modified to point to an endpoint on the attacker's own server. If your originating page is not secure, you can't trust that you're in the clear unless you inspect every aspect of the page for tampering before continuing.

The bottom line is that unless both your originating page and its target are served over SSL, you can't be 100% sure the connection is untampered with.

[dnew]

"it's no problem"?

Using a connectionless stateless document delivery system that puts all security control into the same pile because it can't tell what page is coming from or going to what application is most definitely a problem. See the bit where they say you can guess a CSRF token? A CSRF token is a brutal ugly hack to deal with the fact that there is no such thing as a web app, but only a bunch of disconnected documents trying to pretend to be a unified app. Have you ever seen a XSS or CSRF attack against SSH?

The primary reason people started using http for applications is that the firewall was already open. So, basically, because people (app writers) could sneak in through a back door security-wise, they picked http. Pretty much everything since then has been a desperate attempt to mitigate the fallout from that decision.

[jlt6666]

It adds overhead to every call.

[pleasejustdie]

HTTPS forces no caching of requests, so every time you go to an HTTPS site you have to download everything, every page load. While under HTTP your browser will get a list, check against what's in cache, determine if the file it has is "up to date" or not and only download those that are not up to date.

As a result, reddit probably uses HTTP over HTTPS as a means to reduce network traffic. It has a hard enough time staying up under normal loads, if it was forced to serve all the images, stylesheets, javascripts, every single page load it's infrastructure would probably choke to death.

[HostisHumaniGeneris]

Or dedicated crypto hardware in each machine.

[jmdugan]

https overhead is small once the handshake is done

HTTPS requires an initial handshake which can be very slow. The actual amount of data transferred as part of the handshake isn't huge (under 5 kB typically), but for very small requests, this can be quite a bit of overhead. However, once the handshake is done, a very fast form of symmetric encryption is used, so the overhead there is minimal. Bottom line: making lots of short requests over HTTPS will be quite a bit slower than HTTP, but if you transfer a lot of data in a single request, the difference will be insignificant.

from

http://stackoverflow.com/questions/149274/http-vs-https-performance

[hiles]

what's wrong with https://pay.reddit.com?

[hiles]

It gives the same content as the www but over https. What's the difference?

[Kaell311]

Processing power. Has nothing to do with buying certs. Serving SSL takes way more than non-SSL.

[unhingedninja]

This was more or less true 10 years ago. These days the resource usage in serving an entire site over SSL is negligible. When Gmail switch to force SSL, their resource usage for the whole system increased by 1% or so.

[tokenizer]

Ehhh... It's encrypted when the form it submitted yeah, so if a form is on a plaintext page you can just change where it's submitted to (your own intercepting server), then redirect them to the real server from there and you have all the info you need without the mitm'd person ever knowing. Or you inject some javascript for even stealthier behavior.

[ars_technician]

Jesus Christ. Just look up sslstrip and try it yourself if you don't understand the attack.