How secure is SSL?
 

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.

doubt on ssl security
 

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.

Yikes! If that's the case, I wonder why their certificate hasn't been revoked yet.

True that.

I agree. It seems that's the only workaround until a more permanent solution is found. Fundamentally, though, it's an issue of trust, so I can't envision a technological solution to it. We'll just need to limit ourselves to CAs which we can really trust. That might entail developing our own trust criteria and then going through each one of our browser's certificates to delete those that don't meet it. And even then, we're still vulnerable to being hit by those CAs themselves - which again raises the issue of trust.

Great article, thanks.

Okay, I see what you were getting at originally.

That does makes sense when you look at it in this context (even if it's infeasible).

Yeah I think the fact you could get hit on the first download kinda defeats its purpose. If you don't mind the privacy implications, maybe you could have your browser query your major CAs (we could call them "super-trusted") directly to check whether they have signed a certificate for the relevant IP/domain too. I don't know, man. Like I said, I don't really see a technological solution for this. I think in the end we'll have to take legislative measures that allow people that do this to be put in prison.

Maybe because no one has really investigated this yet?
They keep everything vague on their website as if they don't really want to tell you how exactly their software works.
I would like to get hold of their software to check this out myself and in case find out which CA's certificate they are using (if that's really the case), but even though they provide demo versions, the download is not automated, they have human checks to make sure you are a valid potential customer.

Don't even suggest that as a joke, politicians who go anywhere near technology issues usually just make things worse with very bad laws!

I don't have a link, but there is a project going on which is based on the idea that you can be reasonably safe a certificate is genuine if you retrieve it from different locations (IP addresses) and the certificates you get from all IP addresses match (it's very unlikely that all those IPs are subject to the same MITM attack).

Else, once we have DNSsec maybe that could be used to verify the SSL certificates for the related domains? I don't know enough about DNSsec to tell if that's feasible and not exploitable in other ways.

Haha, fair enough.

I appreciate the work which people are presumably putting into mitigating this threat. I hope someone comes up with something that won't be just a band-aid, though. How effective would this multiple-IP approach be if the MITM was on the firewall in front of the server? Zero effective.

Ditto.

more references needed
 

The new thing I understood now is "the data encrypted by the client using the server key can only be decrypted by server with its' private key". I understood now the mechanism is really secure, but I would like to know in depth detail about how above mechanism is achieved. If this mechanism is known to public, isn't possible for them decrypt the data again?

Wikipedia has great articles such as this one, which provide a good overview.