In short, at least one CA, Trustwave, has issued a "subordinate CA certificate" (which allows another party to issue certs which will be trusted as if they were from Trustwave) to a network admin who used it to create forged certificates and intercept SSL traffic on their internal network.
Has there been any talk about which company received the subordinated cert? The excuse for it being used in an internal network only doesn't really hold any weight due to the ability to install custom certs on all web browsers.
Apparently some root certificate authorities have been issuing certificates that lets others generate their own, valid certificates at their own discretion. Sounds these subordinate CA certificates are being used for SSL man-in-the-middle attacks (http://en.wikipedia.org/wiki/Man-in-the-middle_attack).
So say your employer wants to monitor everything you're doing at work. In order to get around the fact that a lot of your network data is encrypted, they put in a device between your network connection and the internet that looks at all your network traffic. For any connection that is SSL encrypted (like https pages), it will forge its own valid certificate, and use it to prove to your web browser (etc) that nothing is wrong with the connection. Meanwhile, its logging the content of your Gmail, etc.
If an employer wants to snoop they usually install a root cert on your machine. That's cause you, the user, do not have physical control of the machine. What is new with this is that if you have full control of your hardware, someone can man in the middle attack you now. This is serious. It could be used by any ISP or government to snoop on all the traffic on it's network or country.
This is the unfortunate flaw with SSL and TLS. The certificates are bound only to the "domain name" which is a wobbly concept at best without DNSsec to validate your DNS responses.
Anyone clever enough to create a DNS redirector that turns paypal.com into 10.0.0.2 on their closed network could also create an accompanying SSL certificate that they own for paypal.com and you'd be none the wiser as they proxy all of your traffic through their server, logging every bit of it.
Wait, what? No they can't. The whole point of SSL/TLS is that you don't trust the DNS.
The only way an attacker can redirect DNS for Paypal and have a valid-looking CA for Paypal is if they compromise a CA root certificate. That's the point of SSL/TLS.
Before you suggest "but we can't trust the CAs", note two things: (1) if you don't trust the CA, SSL/TLS isn't doing anything for you anyways, and (2) DNSSEC also has a hierarchical PKI in which you are required to trust commercial enterprises --- or governments, explicitly.
SSH has more robust security than SSL seems to if only because once you've established a connection with a remote host, whereupon their public key is displayed and validated, it can be saved as "trusted".
The same principle doesn't seem to apply for SSL in browsers where, so long as it's signed by a "trusted" authority, there's no question the certificate is valid.
And even if the IP address is unaltered - what will prevent the owner of the closed network from routing every http(s) request silently through a proxy on its way out to the Internet?
In a corporate setting in which you use a computer provided by your employer this will always be possible. You can do it by simply generating your own CA certificate and making sure every browser used throughout the company has it in its CA cert list.
