4 ms·

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

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.

pjmlp 9y ago
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.
- laumars 9y ago
  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?
  - pjmlp 9y ago
    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.
    - Freak_NL 9y ago
      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.
      - laumars 9y ago
        > 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.
- agrajag 9y ago
  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.
  - pjmlp 9y ago
    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.
    - dx034 9y ago
      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.
      - pjmlp 9y ago
        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.
        laumars 9y ago
        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.0.2C_2.0_and_3.0 https://en.wikipedia.org/wiki/Transport_Layer_Security#SSL_1...
- lmm 9y ago
  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-numbers http://www.bgplookingglass.com/list-of-autonomous-system-num...
xfer 9y ago
The question was about static HTML pages, so the government can track what you are reading or watching.
will_hughes 9y ago
> 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.
- tajen 9y ago
  Does that mean Hilton makes 15€/day injecting users who don't secure their traffic?
- nandhp 9y ago
  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"?
blfr 9y ago
> 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.
- 3pt14159 9y ago
  Not really. Just put a root level cert or two as your backups.
tonyarkles 9y ago
3%?! Do you have a link where I can read more? That's horrifying!

pjmlp 9y ago

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.

laumars 9y ago
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?
- pjmlp 9y ago
  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.
  - Freak_NL 9y ago
    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.
    - laumars 9y ago
      > 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.
agrajag 9y ago
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.
- pjmlp 9y ago
  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.
  - dx034 9y ago
    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.
    - pjmlp 9y ago
      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.
      - laumars 9y ago
        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.0.2C_2.0_and_3.0 https://en.wikipedia.org/wiki/Transport_Layer_Security#SSL_1...
lmm 9y ago
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-numbers http://www.bgplookingglass.com/list-of-autonomous-system-num...

xfer 9y ago

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

will_hughes 9y ago

> 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.

tajen 9y ago
Does that mean Hilton makes 15€/day injecting users who don't secure their traffic?
nandhp 9y ago
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"?

blfr 9y ago

> 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.

3pt14159 9y ago
Not really. Just put a root level cert or two as your backups.

tonyarkles 9y ago

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