Hacker News Reader

Comment by 3pt14159 | Hacker News Reader

3% of routers in Canada and the US have some kind of malware in them, and almost all other countries are worse off. You might not need HTTPS, but I need you to have it so I can trust downloading a PDF when I'm on your site. I need it so I don't get MITM by some shitty black hat tracking company. I need it so while I travel I don't have to worry about shitty governments tracking what I'm reading or watching.

And if your answer is "sure, but there will be other websites that are HTTP" my response is "yeah, but one day soon when enough of the web is secure I'm going to disallow all HTTP connections from my browser". And eventually I'll disallow all connections that aren't on HSTS preload lists. And eventually, hopefully, I'll disallow websites that don't have HPKP with long expires.

View on HN

> eventually, hopefully, I'll disallow websites that don't have HPKP with long expires

I doubt HPKP will ever see wide adoption. At least not in the form it has now. It's just too damn easy to bork the config and take your entire site offline with no way to remedy that error.

Not really. Just put a root level cert or two as your backups.

Then let me tell you it is quite easy to MITM by any company owning part of the connection.

Many moons ago I was using a proxy engine capable of unpacking/packing HTTPS requests.

It was an in-house proxy taking advantage of Apache and IIS APIs for certificate management and SSL connections.

We used it for debugging secure connections, but I can easily envision other purposes.

Many years have passed since 2000, but I am quite sure it is still quite possible to do it.

I won't comment on how you built your proxy but HTTPS has come a long way since, eg TLS wasn't common back then and SSL has since been deprecated.

These days the only viable way to MITM HTTPS is to either attack the connection while it's in plain text HTTP (ie before the browser redirects to HTTPS:// (which is where the HSTS header comes in to play - it's cached by browsers telling them to default to HTTPS and never attempt a plain text connection) or to form your own HTTPS connection with your own CA signed certificate for the target site. Which would mean you'd either need to compromise a signing authority or have your own CA certs already installed on the victims PC (the latter is what some bad ISPs reportedly do when they inject ads).

Edit: I believe some corporate network proxies also work on the principal of having their own CA certs on their business workstations - so maybe this was how your proxy worked as well?

I can't disclose much, but can give a very basic idea regarding SSL.

That information eventually needs to be unpacked, so you get a replicate of the destination site with the same certificates, which you can easily download by pretending to be a browser, but running on your modified server, which then unwraps, repackages and then forwards the request to the original server.

Since one owns the server, it is also relatively easy to disable whatever validations the SSL algorithm requires at library level.

So I don't know TLS and since 2000 I don't mess with this kind of stuff, but I don't think similar approaches aren't possible.

You can't download the private part of the TLS certificate by pretending to be a browser. You can't publicly download it at all. Your browser comes with a chain of public certificates from reputable CA vendors, and you verify that a site is who it claims to be by using their public certificate (which your browser downloads).

The only way they can succeed in proving who they are, is if their server has access to the corresponding private key of the certificate, which is why you can't spoof a properly secured site unless you either hack their server, crack the encryption, or install your phony certificate on the client (which is what corporations sometimes mandate). That's it.

It's been 17 years since 2000. Whatever security hole you may have used (if any) has long since been patched. The weak cyphers used in some SSL versions which you may have depended on are mostly gone (certainly from high profile targets).

If what you state is true, now in 2017, then there would have to be a huge conspiracy which involves all browser vendors (including Mozilla), as well as all national governments and the EU that hides this fact from the people. All software developers who do catch on (the relevant source code is open source after all) would have to bribed or threatened into silence too.

You are either misinformed or consciously spreading misinformation.

> It's been 17 years since 2000. Whatever security hole you may have used (if any) has long since been patched. The weak cyphers used in some SSL versions which you may have depended on are mostly gone (certainly from high profile targets).

I very much doubt he was even doing anything that clever. Since it was a corporate network he probably just had their corporate CA certificate already built as part of the company machine images / build scripts. He possibly might not even have been aware this was happening if the IT department was large enough that different coworkers managed the desktops from himself.

The "I can't disclose much" argument on a 2 decade old hack is effectively just saying "I can't remember the details" or "I wasn't directly involved in setting up the proxy". Either way, while much has changed in the last 17 years, the practice of some businesses installing their own CA certificates on company assets has been a fairly standard way for corporate proxies to intercept HTTPS traffic. And a great deal less trouble than relying on SSL vulnerabilities since you already own and deploy the destination hardware+software anyway.

Anyone can easily find me on the net and I don't need to have fun speaking with lawyers.

Believe me or not, I don't care.

I don't really understand what lawyers have to do with the discussion but I certainly do believe you that you had an in-house proxy that did MITM HTTPS traffic. Lots of businesses do. The problem is you said "let me tell you it is quite easy to MITM by any company owning part of the connection" using that as your example. While your anecdote may be true, the statement it is trying to support simply isn't true and neither was your description of how SSL works (eg the proxy server being able to disable the client libraries SSL checks).

So it's not that I don't believe your anecdote - I'm sure that did happen in some form or other - but the nature of the exploit either isn't how you described or is so old and long since patched that it hasn't been exploitable in more than a decade thus isn't relevant to the statement you were trying to support.

They are not. Either I get content as the key'ed server sent it, or I do not. MITM of a https source under the same domain is not possible (caveate is manually accepting a new certificate in my local browser).

You're loosely describing the 2nd attack I mentioned but overlooking the issue of the SSL handshake. You cannot perform your attack without having the server's private key, which as name suggests, is privately stored on the remote TLS endpoint. The private key is used to confirm that the client has received the websites certificates without getting MITMed. Since you don't have the websites private key you cannot use their public key in the way you described.

The workaround for that is to create your own SSL certificate for that website (this will create you a public certificate and private key). Which means you will also need that new certificate CA signed otherwise the client (who's own SSL validations you cannot remotely disable like you implied) will give the user a warning about an untrusted certificate (the message will vary from client to client). This means you either need access to the targeted client to install your own CA certs, or you need access to a compromised signing authority.

Or for smtp and imap traffic to do a downgrade attack (STARTTLS downgrade). The committee that set encryption to be optional and downgradable in modern smtp/imap over TLS should be placed against a wall. In the history of moronic decisions... All that to save a port.

Proxies that do https inspection act as a client to the destination server, decrypt traffic, then reencrypt locally using a self-signed (or otherwise non publically trusted) certificate.

In short, you can intercept the traffic, but it relies on the client explicitly trusting your certificate. This is the foundation of all security on the web.

My certificate is the original certificate.

We weren't using an off-the-shelf proxy, rather some nice debugging tools with extra help from the networking layering.

Maybe TLS is more full-proof to Website replication with DNS spoofing and a few other tricks, but they did work without issues in SSL 1.0 connections, using modified web servers.

You'd still not be able to MITM traffic while I see the same fingerprint as usually? Either the traffic looks like http to me or it's a different certificate.

We did it, I already explained a bit in another post.

As mentioned this was done with SSL 1.0, I don't know if a similar set of tricks could be done with TLS, as I am out of these type of applications since 2000.

Now believe whatever you want, but I am sure of what I programmed in 2000, the infrastructure we had and gladly explain it in job interviews where confidentiality is assured.

SSL 1.0 wasn't even supported by many of the earlier builds of Internet Explorer on Windows XP, with SSL 2 getting deprecated around the time of XP. Even SSL 3 - the last of the SSL protocols - has now largely been deprecated bar a few misconfigured servers.

Furthermore TLS 1.0 has been supported since XP but even that is now in the process of being deprecated.

So your attack, if it did depend on SSL v1.0, is so outdated that it's not even worth mentioning. And certainly not in the way that you announced "let me tell you it is quite easy to MITM by any company owning part of the connection."

(Please excuse me using "Windows XP" for approximate timeframes. I can't remember the exact year for when these protocols were phased out but I can remember which devices we had to support).

edit: It was bugging me that I didn't really know much about SSL 1.0 compared with the later protocols so I decided to do a bit of reading. It turns out the reason I don't know much about SSL 1.0 was because it was never publically released[1].

Which makes me even more puzzled about your anecdote as why would you even want to run an SSL 1.0 proxy when even back in the year 2000 no devices were supporting it. Either way it's certainly not proof of the ease of which SSL can be MITMed.

[1] https://en.wikipedia.org/wiki/Transport_Layer_Security#SSL_1...

What you are describing does not make sense. TLS would be pointless if this were possible.

People who can MITM you when you use HTTPS: the company that owns the certificate, the software on your local system, people who are capable of subverting one or the other (i.e. state-level attackers), any of the 150-odd CAs if it's willing to burn its entire business to do so (certificate transparency).

People who can MITM you when you use HTTP: any entity on e.g. http://www.bgplookingglass.com/list-of-autonomous-system-num...

> I need it so while I travel I don't have to worry about shitty governments tracking what I'm reading or watching.

For this reason I used a VPN while travelling overseas. Most places have wifi of varying quality. To my dismay/horror, I found that Hilton charge EUR15/day for the privelege of using a VPN.

Does that mean Hilton makes 15€/day injecting users who don't secure their traffic?

Does Hilton actually block VPNs on their standard internet, or is "VPN access" just code for "we'll give you a public IP so that IPsec traffic won't get swallowed"?

The question was about static HTML pages, so the government can track what you are reading or watching.

3%?! Do you have a link where I can read more? That's horrifying!

Reply on news.ycombinator.com