Well, it's not that simple, is it? Generally speaking, the public key algorithm used in SSL is used to protect the private key that is used to protect the data:
1) Site sends public key certificate to browser.
2) Browser verifies certificate against in-browser store.
3) Browser extracts public key from certificate.
4) Browser generates symmetric/private key.
5) Browser encrypts that symmetric key with the site's public key.
6) Browser sends encrypted symmetric key to site.
7) Site decrypts symmetric key with its private key (the one associated with its public key certificate)
8) Site and browser encrypt and decrypt data using the privately shared symmetric key.
If I break the public key algorithm(s) used in SSL, I break all of that. But we think that's tough (as in NP hard).
If I break SSL itself (find flaws in negotiation, etc.) I might be able to break all of that. That's been done a few times (SSL v1.0 is garbage; v2.0 is borked; v3.0 a little broken; only TLS 1.2 is borkless, so far. As far as we know.
If I break the symmetric algorithm(s), then I can get at the data without breaking SSL itself. But we think that's tough, too. As far as we know.
If any of the software used in any of the above is borked, then usable attack vectors may be exist. Or not. We don't know until we find them.
It's a complex box of moving parts with many potential attack vectors, many potential vulnerabilities, etc.
Who really knows if the NSA might have found a multi-vector, multi-vulnerability attack that allows them to get at a lot of encrypted data without having broken all of any one of those things.
It's purest speculation until someone with a sufficient clearance and sufficient need-to-know decides to speak out, and even then it would remain unconfirmed.
1) Site sends public key certificate to browser. 2) Browser verifies certificate against in-browser store. 3) Browser extracts public key from certificate. 4) Browser generates symmetric/private key. 5) Browser encrypts that symmetric key with the site's public key. 6) Browser sends encrypted symmetric key to site. 7) Site decrypts symmetric key with its private key (the one associated with its public key certificate) 8) Site and browser encrypt and decrypt data using the privately shared symmetric key.
If I break the public key algorithm(s) used in SSL, I break all of that. But we think that's tough (as in NP hard).
If I break SSL itself (find flaws in negotiation, etc.) I might be able to break all of that. That's been done a few times (SSL v1.0 is garbage; v2.0 is borked; v3.0 a little broken; only TLS 1.2 is borkless, so far. As far as we know.
If I break the symmetric algorithm(s), then I can get at the data without breaking SSL itself. But we think that's tough, too. As far as we know.
If any of the software used in any of the above is borked, then usable attack vectors may be exist. Or not. We don't know until we find them.
It's a complex box of moving parts with many potential attack vectors, many potential vulnerabilities, etc.
Who really knows if the NSA might have found a multi-vector, multi-vulnerability attack that allows them to get at a lot of encrypted data without having broken all of any one of those things.
It's purest speculation until someone with a sufficient clearance and sufficient need-to-know decides to speak out, and even then it would remain unconfirmed.