3 ms·

Expanding on 1) you can also play man in the middle, decrypt and resign traffic with your own faked CA. If you ever have access to the users' machine you can i

Expanding on 1) you can also play man in the middle, decrypt and resign traffic with your own faked CA. If you ever have access to the users' machine you can install your faked CA as trusted and could have done it long in advance (eg via trojans/viruses). When I was working on WAN optimizers I actually did this during research. All the various sites I visited still proudly told me how they were "Verisign Trusted" and even clicking on "Verify" links would tell me how verified and correct it was. The UI in the browsers tries hard, but in reality users want to access the site and they will hit OK to get there. convergence is nice (if you run Firefox) but it is of significantly less help when using corporate/intranet sites.

marshray 15y ago
It's not a "faked CA", it's a perfectly legitimate "internal CA" you created. Of course you may be using it to impersonate external websites to your internal users, but the circumstances under which that may be an OK thing to do is a policy question that's still evolving.
chc 15y ago
If you've already owned the box, why would you bother with MITM?
- SoftwareMaven 15y ago
  In the corporate world, it is used a lot for data loss prevention policies. It keeps employees from sending a file containing all their customers' social security numbers, addresses, and credit card to their home email account (or even one of them).
- rogerbinns 15y ago
  I was working on WAN optimisers - ie something that would be sold to customers. With WAN optimizers you would typically put one in a branch office and one at headquarters. The boxes would then compress traffic between them. Typical compression ratios are 20x/95% - in other words your WAN link can now transfer about 20 times as much traffic. Additionally some traffic would be modified to do read ahead and write behind to provide latency improvements. An example of that was a user in Malaysia opening a Word document in San Jose, CA that was a 75kb file. Without a WAN optimiser it would take almost 3 minutes while with one it would take 5 seconds. The problem with SSL traffic is that it is encrypted and doesn't repeat even for identical underlying data, and hence can't be compressed, nor can it be modified. This significantly hurts performance. To work well the SSL would need to be stripped off, the traffic compressed/read ahead etc, sent over the WAN and then SSL put back on. (The communication between the WAN optimisers was itself within IPSec or SSL.) SSL is designed so that you can't pull shenanigans like this, unless you have the private key of the servers, or resign the traffic with a different CA that can generate the needed certificates on the fly and are "trusted" by the user. Many internal corporate services have moved to SSL and branch office users need to access them. Think about benefits systems, HR, documents, accounting, sales forecasting and tracking etc.

marshray 15y ago

It's not a "faked CA", it's a perfectly legitimate "internal CA" you created. Of course you may be using it to impersonate external websites to your internal users, but the circumstances under which that may be an OK thing to do is a policy question that's still evolving.

chc 15y ago

If you've already owned the box, why would you bother with MITM?

SoftwareMaven 15y ago
In the corporate world, it is used a lot for data loss prevention policies. It keeps employees from sending a file containing all their customers' social security numbers, addresses, and credit card to their home email account (or even one of them).
rogerbinns 15y ago
I was working on WAN optimisers - ie something that would be sold to customers. With WAN optimizers you would typically put one in a branch office and one at headquarters. The boxes would then compress traffic between them. Typical compression ratios are 20x/95% - in other words your WAN link can now transfer about 20 times as much traffic. Additionally some traffic would be modified to do read ahead and write behind to provide latency improvements. An example of that was a user in Malaysia opening a Word document in San Jose, CA that was a 75kb file. Without a WAN optimiser it would take almost 3 minutes while with one it would take 5 seconds. The problem with SSL traffic is that it is encrypted and doesn't repeat even for identical underlying data, and hence can't be compressed, nor can it be modified. This significantly hurts performance. To work well the SSL would need to be stripped off, the traffic compressed/read ahead etc, sent over the WAN and then SSL put back on. (The communication between the WAN optimisers was itself within IPSec or SSL.) SSL is designed so that you can't pull shenanigans like this, unless you have the private key of the servers, or resign the traffic with a different CA that can generate the needed certificates on the fly and are "trusted" by the user. Many internal corporate services have moved to SSL and branch office users need to access them. Think about benefits systems, HR, documents, accounting, sales forecasting and tracking etc.