How secure is SSL?

Lets talk about 2 scenarios:
#1. A credit card is passed to the merchant, via a customer from a form on their website

#2. A credit card is passed to the customer from the merchant, via something like and "Account Details" page.

If someone is sniffing the network, is there any chance the "encrypted SSL data" could be decrypted in either case? For example if the public key was grabbed by the sniffer and used decrypt the captured encrypted packets?

Note: I am just asking here if this is possible, please do not post how to do it, what software to use, etc.

TIA!

it's possible, yes. Especially with SSL 2.0 which is known to have a number of MITM related flaws. MITM's under SSL 3 / TLS are much harder, to the point that it's not considered a risk that requires attention, as i believe you'd need the server certificates anyway which would mean you had plenty of other worse and easier things you could be doing.

most browsers permit disabling of ssl2, but this can also be done implictly by only permitting cryptographic ciphers present in ssl3, not 2.

Would either scenario #1 or #2 be easier than the other?

For #2 it seems you may not need the server private key, because everything you'd need to decrypt the SSL the customer's browser would have. So theorectically a sniffer would be able to get everything it needs to decrypt a stream going to the client. Is that correct?

No difference to my knowledge, as it's the stream that's encrypted as a whole.

But the client would have access to decrypt that string, no?

Otherwise it would just display jibberish in the browser.

When you encrypt something with a public key, it can only be decrypted by the accompanying private key. Grabbing the public key with a sniffer doesn't accomplish anything, it's designed to be available to anyone who wants it. Also, I would point out that the credit card number (or anything else you are sending to the server) doesn't itself get encrypted with the public key. The public key is used to encrypt a random key (generated by the client) which is what is used for the actual message transmission. That doesn't add security in and of itself, but it allows a symmetric (shared key) setup to be created.

So, basically, your browser generates a random key; encrypts your credit card number using that random key; encrypts the random key using the server's public key; and then sends both of those to the server. The server decrypts the random key using it's private key, then uses that to decrypt the credit card number. The server can then reply to the client with a message encrypted using the random key - they now have a symmetric setup to work with.

I mean that the client and server have used their certificates to secretly agree new encryption secrets, and use the same symmetrical encryption (afaik) so you can't just decrypt traffic in one direction, it's all or nothing.

But a sniffer could capture the client's random key and use that to decrypt streams FROM the server though, correct?

no, because it's sent as encrypted data which can only be decrypted with *private* data which never leaves the box at each end.

Ah, thanks, makse sense now.

What is it, that is never exchanged but common/known only to both client and server during an https connection? I have another question based on the response this question.

Could you rephrase your question please? It's not entirely clear what it is that you are asking. The server's public key is known to everyone. The server's private key is known only to the server. The randomly-generated symmetric key is only known to the client and the server.

MITM attacks on any SSL connection (even 3.0) are quite possible, there is even a commercial product that does just this, which generally gets used on company network gateways to inspect ssl traffic of the employees.
See here:
http://summerweb.microdasys.com/prod...-and-benefits/

The same thing could be done by hackers or by your ISP (obviously with bigger traffic volumes to inspect, very powerful hardware is needed)

The only way to avoid this would be if the browser keeps a copy of the public key of the https server you are connecting to (ideally this copy should have been provided offline, for example in person or via mail on a memory card) and then compares the key at each connection (sort of like SSH does).

Keep in mind that saying you are "inspecting SSL traffic" is a misrepresentation, though. You are inspecting traffic which has been decrypted by the gateway, which is only feasible due to the fact that you had the clients encrypt it using the gateway's public key (instead of the server's). This is relatively easy to do in a corporative environment, since you can easily force the client hosts to accept the gateway's bogus certificate with or without the user's knowledge. Making this work outside the corporate environment is a whole different ballgame, which would require the exploitation of vulnerabilities either in the client's software or the user's minds (social engineering). It could also involve gaining physical access to the user's machine and secretly accepting the bogus certificate on their behalf.

Ummm, no. We normally just check whether the certificate has been signed by a trusted third party. It would be insane if we needed to posses every HTTPS server's public key prior to the initial handshake. The important thing to point out is that on computers you don't have full control over (such as is the case in a lot of people's work environment), there's no telling what bogus certificates might have been accepted on your behalf (in order to deploy MITM-based analysis solutions). Refraining from using your work computer for personal matters is a good habit to get into, as is refraining from letting other people use your account.

The thing is, the Microdasys SKIP apparently doesn't require any certificate to be installed on the clients, according to people who have direct experience with it (I don't).
I can only imagine that means that it comes with a certificate built in that has been signed by one of the many 'trusted' CAs, with delegated CA authority.
Even outside the corporate environment all you need is a valid certificate from any one of the many CAs trusted by default in browsers (IE has more than 100!) and control of the DNS the client is using (which any ISP has).

And that's the weak point! Do you trust all 50-100+ CAs that your browser trusts by default?
I don't, and therefore I have a separate browser installation only for online banking that only contains the certificate of the CA used by my online bank (I deleted all other default certificates), but this is only a clumsy stop-gap to a the fundamental insecurity of the SSL trust scheme.

All you need is one foul apple in between and the whole chain of trust is broken.
Just because your online bank uses for example Verisign (as many banks do), that doesn't mean that your browser wouldn't accept a valid certificate for it from any other CA too!
See here too for a real example:
http://www.theregister.co.uk/2008/12...lla_cert_snaf/

Of course we cannot realistically have public keys for every https server we interact with, but online banks should start providing them offline for maximum security.
Also my suggestion is that the browser stores certificates the first time it gets them and then later warns you if they change (unless they change because they have reached their expiry date), similar to how SSH does it.
Of course if the key you get the first time is bogus this won't help, but it still adds a layer of security for most situations.

Agreed and many people don't even realize this.