4 ms·

Vanilla browser based https encryption cannot stop states like the US or China which have access to all the major pipes. All it takes to do a man in the middle

Vanilla browser based https encryption cannot stop states like the US or China which have access to all the major pipes. All it takes to do a man in the middle on basic https is the key for any one certificate that your browser trusts. Any organization that has one (including many employers which install certs) can easily watch your traffic. HTTPS is fundamentally insecure against MITM attacks by governments.

deleted 17y ago
[deleted]
ronnier 17y ago
While I was in China, I remoted back to my home computer through a remote desktop session to check email. I also tunneled my RDP session through an SSH proxy. Hopefully that was secure enough. I also changed my passwords once I returned home.
- deleted 17y ago
  [deleted]
- onedognight 17y ago
  Once you have the host key for the site you are connecting to on your laptop SSH is not vulnerable to a MITM attack in the same way that browsers are with their huge CA list. Of course, pay attention to the warnings about changed host keys.
  - swolchok 17y ago
    Patently false. If users submit to the login URL through a link that was sent in the clear, a MITM can just run sslstrip (http://www.thoughtcrime.org/software/sslstrip/ http://www.thoughtcrime.org/software/sslstrip/) and presto, you're visiting the HTTP version of the page instead of HTTPS. The login URL needs to be unavailable over HTTP, as does the login form.
    - wooster 17y ago
      Wrong parent post? SSL != SSH
      - swolchok 17y ago
        You're right, I misread SSH as SSL.
adamsmith 17y ago
Hm. I wonder how often this happens. We should be able to detect it easily if they do it all the time. Today they don't have to. For the long term I wonder if it's possible to close this hole by putting certs into DNS and using a single key to sign all of these DNS records. Is this part of the DNSSEC spec? (not at a computer and can't remember for sure if it is called DNSSEC; whatever the name of the next gen DNS is.)
- tptacek 17y ago
  The original intent of DNSSEC was to provide an IETF-endorsed public key infrastructure, not to defend the DNS from attacks. The idea was, "we have this great DNS protocol, it works well at Internet-scale, let's leverage it for something other than hostname resolution". The reality of DNSSEC is that it's creaky, somewhat broken, solves neither the PKI nor the DNS protection problem well, and --- because it is likely to pervasively screw up applications across the Internet --- unlikely ever to be deployed. Either way, there's no magic bullet. If you concede root keys to China, you have to concede DNSSEC keys --- which are, if anything, more loosely held and more widely distributed than CA keys, which have never had a known breach.
Retric 17y ago
A MITM attack of this nature would be easy for a website owner to discover. Just compare the public keys with what a random browser is receiving. Edit: CA operates based on trust. All it takes is for a single website to demonstrate this is going on for it to quickly become public knowledge. Now, if you where to target a specific user it might be possible to do this, but hacking their system is a much simpler approach to the same problem with more benefits.
- onedognight 17y ago
  Not in the long run since any HTML/JS code you send at that point is vulnerable as well.
tptacek 17y ago
I think the spirit of your comment is pure tinfoil-hat, but the letter of it is actually valid. It is vanishingly unlikely --- on the level of "major diplomatic incident" --- that China (or any other government, including ours) has the key associated with Verisign's root CA certificate. It is somewhat more likely (but still, I think, pretty unlikely) that one of the following could have happened: * Your computer is controlled by an employer that installed a deliberately insecure certificate. * Your computer is infected with malware that poisons the CA store in your browser. The first scenario is just very unlikely. We work extensively on-site for Fortune 500 enterprises, in some of the highest-security environments in the world (and in some of the most idiosyncratic and crazy), and none of them require us to install bespoke certificates to access the Internet or their websites. Now, you have to find the one employer (or zero ISPs) that not only installed a custom root, but also gave the keys to China. The second point is irrelevant. If your computer is infected with malware, there are worse things to be done to you than injecting bogus certificates. It is almost the case that it's worth pruning out certs from your browser from untrustworthy CAs; unfortunately, the market for certificates has devolved to "who will give us a cert the cheapest". I wouldn't know which ones to kill. A year or so ago, pruning out untrustworthy CAs would have protected you from the MD5 problem.
- wooster 17y ago
  "The first scenario is just very unlikely." From another perspective: I worked on the content filter for Parental Controls at Apple. My understanding is that every filtering proxy product with SSL support requires the installation of an insecure certificate. That, or they do a fairly rudimentary IP or reverse-DNS based filtering (which is the route we chose for Parental Controls) for secure connections. These vendors certainly claim to have a lot of Fortune 500 clients.
  - tptacek 17y ago
    You're thinking of, e.g. Bluecoat. Certainly everyone runs something like a Bluecoat. But I can't name a client that uses the feature where your end users install the Bluecoat cert so they can scrub SSL traffic. They just use IP and DNS blacklists, like you.
run4yourlives 17y ago
It's a lot easier just to install a hidden keylogger then it is to fart around with certs and try to crack https. Google even references this in the press releases - most of the information gained was done through phishing.

deleted 17y ago

[deleted]

ronnier 17y ago

While I was in China, I remoted back to my home computer through a remote desktop session to check email. I also tunneled my RDP session through an SSH proxy. Hopefully that was secure enough. I also changed my passwords once I returned home.

deleted 17y ago
[deleted]
onedognight 17y ago
Once you have the host key for the site you are connecting to on your laptop SSH is not vulnerable to a MITM attack in the same way that browsers are with their huge CA list. Of course, pay attention to the warnings about changed host keys.
- swolchok 17y ago
  Patently false. If users submit to the login URL through a link that was sent in the clear, a MITM can just run sslstrip (http://www.thoughtcrime.org/software/sslstrip/ http://www.thoughtcrime.org/software/sslstrip/) and presto, you're visiting the HTTP version of the page instead of HTTPS. The login URL needs to be unavailable over HTTP, as does the login form.
  - wooster 17y ago
    Wrong parent post? SSL != SSH
    - swolchok 17y ago
      You're right, I misread SSH as SSL.

adamsmith 17y ago

Hm. I wonder how often this happens. We should be able to detect it easily if they do it all the time. Today they don't have to. For the long term I wonder if it's possible to close this hole by putting certs into DNS and using a single key to sign all of these DNS records. Is this part of the DNSSEC spec? (not at a computer and can't remember for sure if it is called DNSSEC; whatever the name of the next gen DNS is.)

tptacek 17y ago
The original intent of DNSSEC was to provide an IETF-endorsed public key infrastructure, not to defend the DNS from attacks. The idea was, "we have this great DNS protocol, it works well at Internet-scale, let's leverage it for something other than hostname resolution". The reality of DNSSEC is that it's creaky, somewhat broken, solves neither the PKI nor the DNS protection problem well, and --- because it is likely to pervasively screw up applications across the Internet --- unlikely ever to be deployed. Either way, there's no magic bullet. If you concede root keys to China, you have to concede DNSSEC keys --- which are, if anything, more loosely held and more widely distributed than CA keys, which have never had a known breach.

Retric 17y ago

A MITM attack of this nature would be easy for a website owner to discover. Just compare the public keys with what a random browser is receiving. Edit: CA operates based on trust. All it takes is for a single website to demonstrate this is going on for it to quickly become public knowledge. Now, if you where to target a specific user it might be possible to do this, but hacking their system is a much simpler approach to the same problem with more benefits.

onedognight 17y ago
Not in the long run since any HTML/JS code you send at that point is vulnerable as well.

tptacek 17y ago

I think the spirit of your comment is pure tinfoil-hat, but the letter of it is actually valid. It is vanishingly unlikely --- on the level of "major diplomatic incident" --- that China (or any other government, including ours) has the key associated with Verisign's root CA certificate. It is somewhat more likely (but still, I think, pretty unlikely) that one of the following could have happened: * Your computer is controlled by an employer that installed a deliberately insecure certificate. * Your computer is infected with malware that poisons the CA store in your browser. The first scenario is just very unlikely. We work extensively on-site for Fortune 500 enterprises, in some of the highest-security environments in the world (and in some of the most idiosyncratic and crazy), and none of them require us to install bespoke certificates to access the Internet or their websites. Now, you have to find the one employer (or zero ISPs) that not only installed a custom root, but also gave the keys to China. The second point is irrelevant. If your computer is infected with malware, there are worse things to be done to you than injecting bogus certificates. It is almost the case that it's worth pruning out certs from your browser from untrustworthy CAs; unfortunately, the market for certificates has devolved to "who will give us a cert the cheapest". I wouldn't know which ones to kill. A year or so ago, pruning out untrustworthy CAs would have protected you from the MD5 problem.

wooster 17y ago
"The first scenario is just very unlikely." From another perspective: I worked on the content filter for Parental Controls at Apple. My understanding is that every filtering proxy product with SSL support requires the installation of an insecure certificate. That, or they do a fairly rudimentary IP or reverse-DNS based filtering (which is the route we chose for Parental Controls) for secure connections. These vendors certainly claim to have a lot of Fortune 500 clients.
- tptacek 17y ago
  You're thinking of, e.g. Bluecoat. Certainly everyone runs something like a Bluecoat. But I can't name a client that uses the feature where your end users install the Bluecoat cert so they can scrub SSL traffic. They just use IP and DNS blacklists, like you.

run4yourlives 17y ago

It's a lot easier just to install a hidden keylogger then it is to fart around with certs and try to crack https. Google even references this in the press releases - most of the information gained was done through phishing.