LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
Search this Thread
Old 04-13-2009, 11:11 AM   #1
abefroman
Senior Member
 
Registered: Feb 2004
Location: Chicago
Distribution: CentOS
Posts: 1,257

Rep: Reputation: 53
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!
 
Old 04-13-2009, 11:29 AM   #2
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,398

Rep: Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965
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.

Last edited by acid_kewpie; 04-13-2009 at 11:31 AM.
 
Old 04-13-2009, 11:32 AM   #3
abefroman
Senior Member
 
Registered: Feb 2004
Location: Chicago
Distribution: CentOS
Posts: 1,257

Original Poster
Rep: Reputation: 53
Quote:
Originally Posted by acid_kewpie View Post
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.
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?
 
Old 04-13-2009, 11:35 AM   #4
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,398

Rep: Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965
No difference to my knowledge, as it's the stream that's encrypted as a whole.
 
Old 04-13-2009, 11:44 AM   #5
abefroman
Senior Member
 
Registered: Feb 2004
Location: Chicago
Distribution: CentOS
Posts: 1,257

Original Poster
Rep: Reputation: 53
Quote:
Originally Posted by acid_kewpie View Post
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.
 
Old 04-13-2009, 12:48 PM   #6
win32sux
Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
Quote:
Originally Posted by abefroman View Post
For example if the public key was grabbed by the sniffer and used decrypt the captured encrypted packets?
Quote:
Originally Posted by abefroman View Post
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?
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.

Last edited by win32sux; 04-13-2009 at 01:00 PM.
 
Old 04-13-2009, 12:53 PM   #7
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,398

Rep: Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965
Quote:
Originally Posted by abefroman View Post
But the client would have access to decrypt that string, no?

Otherwise it would just display jibberish in the browser.
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.
 
Old 04-13-2009, 01:13 PM   #8
abefroman
Senior Member
 
Registered: Feb 2004
Location: Chicago
Distribution: CentOS
Posts: 1,257

Original Poster
Rep: Reputation: 53
Quote:
Originally Posted by win32sux View Post
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.
But a sniffer could capture the client's random key and use that to decrypt streams FROM the server though, correct?
 
Old 04-13-2009, 01:23 PM   #9
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,398

Rep: Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965Reputation: 1965
no, because it's sent as encrypted data which can only be decrypted with *private* data which never leaves the box at each end.
 
Old 04-13-2009, 02:41 PM   #10
abefroman
Senior Member
 
Registered: Feb 2004
Location: Chicago
Distribution: CentOS
Posts: 1,257

Original Poster
Rep: Reputation: 53
Quote:
Originally Posted by acid_kewpie View Post
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.
 
Old 04-23-2009, 06:46 AM   #11
ramanrv
LQ Newbie
 
Registered: Apr 2009
Posts: 2

Rep: Reputation: 0
doubt on ssl security

Quote:
Originally Posted by acid_kewpie View Post
no, because it's sent as encrypted data which can only be decrypted with *private* data which never leaves the box at each end.
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.

Last edited by ramanrv; 04-23-2009 at 06:47 AM.
 
Old 04-24-2009, 09:45 AM   #12
win32sux
Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
Quote:
Originally Posted by ramanrv View Post
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.
 
Old 04-25-2009, 02:22 AM   #13
tux99
LQ Newbie
 
Registered: Mar 2009
Posts: 20

Rep: Reputation: 3
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).

Last edited by tux99; 04-25-2009 at 02:26 AM.
 
Old 04-25-2009, 03:07 AM   #14
win32sux
Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
Quote:
Originally Posted by tux99 View Post
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)
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.

Quote:
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).
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.

Last edited by win32sux; 04-25-2009 at 03:21 AM.
 
Old 04-25-2009, 06:10 AM   #15
tux99
LQ Newbie
 
Registered: Mar 2009
Posts: 20

Rep: Reputation: 3
Quote:
Originally Posted by win32sux View Post
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.
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).

Quote:
Originally Posted by win32sux View Post
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.
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.

Quote:
Originally Posted by win32sux View Post
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.
Agreed and many people don't even realize this.

Last edited by tux99; 04-25-2009 at 06:21 AM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Secure your webserver using SSL and TinyCA LXer Syndicated Linux News 0 10-08-2007 02:30 PM
LXer: Secure Websites Using SSL And Certificates LXer Syndicated Linux News 0 05-18-2007 12:31 PM
LXer: How to secure WebDAV with SSL and Two-Factor Authentication LXer Syndicated Linux News 0 04-18-2007 09:31 AM
secure. vs www. ssl apache config hank43 Linux - Networking 4 08-09-2006 10:06 PM
Secure email (SSL vs. secure authentication) jrdioko Linux - Newbie 2 11-28-2004 01:39 PM


All times are GMT -5. The time now is 11:58 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration