"Secure" all depends on how long you want to keep the data in the SSL
stream safe from prying eyes. If you're sending the location of a long
lost National Treasure worth billions to your recovery team, you'll
likely want the data to be secure just long enough for the treasure to
be recovered and moved - after that the information becomes worthless
(or worth much less than it was when the treasure was still in place).
Basically figure it as "sensitivity of data" versus "duration of
concealment". The higher either is, the more security you need, and if
both are high, the security requirements can become astronomical.
There's nothing wrong with SSL 128bit these days. It'll keep your
online banking activities safe from casual packet sniffers out on the
net. Anyone with the computing horsepower needed to decrypt the data
stream in any kind of practical time period wouldn't need to steal
your bank password anyways - they could attack the bank directly and
get *everyone's* password. You're far more likely to get into trouble
from spyware on your computer watching what you type and getting
usernames and passwords stole that way.
So... ways of cracking SSL
1) Execute a man-in-the-middle attack - Intercept your SSL request
going to a server and pretend to be that server
- not very practicle unless you're under government surveillance
with enough resources (and time) to set up for it
2) Exploit a vulnerability in your or the other side's SSL software
(bad random number generators, buffer overflows, etc...)
- The SSL portions of browsers tend to be tested pretty well and
checked for bugs by lots of people. Not to say it's impossible (and
there have been problems before), but not too likely
3) Compromise your machine or the remote machine you're connecting to
- Very likely, as it's so very easy to pick up a lot junk with
simple browsing of "safe" sites with Internet Explorer, or reading
email with attachments.
4) and as always, brute force attacks
- Not too likely. Even SSL 128 would require a huge and very fast
computer to attempt guessing all possible keys. If the attacker was
seeking a username/password from the data being brute forced, by the
time the computer managed to crack the SSL encryption, you'd most
likely have changed that password to something else.
As such, I'm personally more worried about my computer (or the remote
server I'm connecting to) being compromised than someone cracking the
SSL layer. It's so much easier to watch someone type in a password,
than it is to decrypt the password from the SSL stream later on.
And... for the previous comment, I don't know what XML has to do with
SSL. It's like saying "new standards like the english language...".
XML is used to define other languages and facilitate data transfers
between disparate systems. It's not and never has been a method of
encryption (though, you could use it to *specify* an encryption
language). A DDoS attack also has nothing to do with SSL . DDoS is the
act of using a large number of computers to flood one (or a few)
servers with so much bogus data that they can't process any more
legitimate attacks. If you meant a distributed computing effort, then
that's a different thing. But a distributed key cracking effort still
boils down to a brute force attack, and ANY encryption scheme, no
matter how powerful of secure, will invariably be broken by such an
attack. |
