Does SSL create a false sense of security

syklops

Ever since the creation of tools like SSLStrip, it has been pretty easy to sniff traffic that is supposed to be secured. The cynical side of me would say the reason it has not been updated or replaced is that the sale of SSL certificates is a nice little earner for too many vested interests and there is no motivation to improve the system.

Is it not time for a better, and preferably free and open solution?

I'd be interested to hear thoughts on the subject.

BaconZombie

New system will take 2-5 years to get academic approval then 5-20 years to get RFC /widespread acceptance.

syklops wrote: »

Ever since the creation of tools like SSLStrip, it has been pretty easy to sniff traffic that is supposed to be secured. The cynical side of me would say the reason it has not been updated or replaced is that the sale of SSL certificates is a nice little earner for too many vested interests and there is no motivation to improve the system.

Is it not time for a better, and preferably free and open solution?

I'd be interested to hear thoughts on the subject.

LoLth

BaconZombie wrote: »

New system will take 2-5 years to get academic approval then 5-20 years to get RFC /widespread acceptance.

true, MD5 is still the accepted hash algorithm for forensic evidence even though it has been shown to have large collision sets. Shah1 is supposed to be better but still has issues that were addressed by Shah2 and now there's shah3 being released...and yet there is no sign of software moving away from MD5/Shah1 (or even moving to shah1 from md5). Any move in encryption security methods seems to be almost glacial...until there's some high profile scare and then its a fire-fighting kneejerk reaction and implementation suffers as a result.

ChRoMe

syklops wrote: »

Ever since the creation of tools like SSLStrip, it has been pretty easy to sniff traffic that is supposed to be secured. The cynical side of me would say the reason it has not been updated or replaced is that the sale of SSL certificates is a nice little earner for too many vested interests and there is no motivation to improve the system.

Is it not time for a better, and preferably free and open solution?

I'd be interested to hear thoughts on the subject.

SSLStrip doesn't really remove SSL's security. Its just a man in the middle attack, the crypto is still rock solid.

Khannie

ChRoMe wrote: »

SSLStrip doesn't really remove SSL's security. Its just a man in the middle attack, the crypto is still rock solid.

Yeah, but it simply being there gives people the impression that they're safe. The reality is that it's possible for your IT guy to push a trusted man in the middle cert to your OS (sophos provide software to do this for you for example). You think you're safe. The padlock is there. The reality is that you're getting the shaft.

syklops

ChRoMe wrote: »

SSLStrip doesn't really remove SSL's security. Its just a man in the middle attack, the crypto is still rock solid.

What Khannie said. The crypto might be bullet proof but if I can read your traffic then it doesnt work.

ChRoMe

syklops wrote: »

What Khannie said. The crypto might be bullet proof but if I can read your traffic then it doesnt work.

You need to be in a very privileged position to pull off that attack. So if you have someone malicious there, HTTPS being sniffed is the absolute least of your worries.

Khannie

Really all it would take is physical access, an unencrypted hard drive and a mild desire to shaft you.

But yeah, I take your point.

syklops

ChRoMe wrote: »

You need to be in a very privileged position to pull off that attack. So if you have someone malicious there, HTTPS being sniffed is the absolute least of your worries.

All you need is to be on the same LAN as them. Thats not that privileged nowadays.

Khannie

syklops wrote: »

All you need is to be on the same LAN as them. Thats not that privileged nowadays.

Same lan plus either admin rights on the box (that's why I said the "IT guy") or physical access + unencrypted hard drive.

There are easier ways though. A keylogger springs to mind immediately if you have that kind of privilege or access already.

When trying to secure my own box, I sat down and thought about building a box secure enough that I couldn't break into it with any amount of time, effort or money. It's really the only way to approach securing yourself.

syklops

Khannie wrote: »

Same lan plus either admin rights on the box (that's why I said the "IT guy") or physical access + unencrypted hard drive.
.

Im not sure I follow. To sniff someone elses traffic all I need is my linux box on the LAN. I don't need physical access to their machine.

When trying to secure my own box, I sat down and thought about building a box secure enough that I couldn't break into it with any amount of time, effort or money. It's really the only way to approach securing yourself.

Again, if you are relying on SSL, then I can sniff your traffic strip off the SSL and I can see your stuff. Unless you are using ssh tunnels or something, I now have whatever you put on the web.

ChRoMe

Khannie wrote: »

When trying to secure my own box, I sat down and thought about building a box secure enough that I couldn't break into it with any amount of time, effort or money. It's really the only way to approach securing yourself.

Really the only solution to that problem is something not connected to any network, with no external ports, locked in a bunker.

And even then....

srsly78

syklops wrote: »

Im not sure I follow. To sniff someone elses traffic all I need is my linux box on the LAN. I don't need physical access to their machine.

Again, if you are relying on SSL, then I can sniff your traffic strip off the SSL and I can see your stuff. Unless you are using ssh tunnels or something, I now have whatever you put on the web.

There is nothing wrong with SSL, you are just talking about man in the middle stuff. SSLStrip just rewrites packets replacing https with http - it doesn't actually hack SSL, it doesn't work on websites with properly configured security.

ChRoMe

srsly78 wrote: »

There is nothing wrong with SSL, you are just talking about man in the middle stuff. SSLStrip just rewrites packets replacing https with http - it doesn't actually hack SSL, it doesn't work on websites with properly configured security.

What would you identify as being the configuration to properly guard against the attack?

Khannie

ChRoMe wrote: »

Really the only solution to that problem is something not connected to any network, with no external ports, locked in a bunker.

And even then....

Ha! Actually I think I achieved it. Unless a vulnerability is found in OpenSSH I feel like my current box is more or less secure even from physical access - barring me being a muppet of course (which, to date and to the best of my knowledge, I have avoided). I am now definitely the weakest link in the chain though.

syklops

Khannie wrote: »

Ha! Actually I think I achieved it. Unless a vulnerability is found in OpenSSH I feel like my current box is more or less secure even from physical access - barring me being a muppet of course (which, to date and to the best of my knowledge, I have avoided). I am now definitely the weakest link in the chain though.

I think we are getting into a different area. I am not talking about the security of your box, I am talking about the security of your data while it is in transit .

Do you feel safe to post over SSL on public or semi public networks?

srsly78 wrote:

There is nothing wrong with SSL, you are just talking about man in the middle stuff.

Yes, I am talking about Man in the middle stuff. SSL is vulnerable to MitM attacks, and so I am asking is it enough? Or should we think about developing something better?

BaconZombie wrote:

New system will take 2-5 years to get academic approval then 5-20 years to get RFC /widespread acceptance.

Whats your point?

Khannie

syklops wrote: »

I think we are getting into a different area. I am not talking about the security of your box, I am talking about the security of your data while it is in transit .

Ah we are, yeah. It had diverged a bit.

syklops wrote: »

Do you feel safe to post over SSL on public or semi public networks?

I would, for the most part, yes. I've sent stuff over public networks in faraway places and felt secure doing it.

srsly78

ChRoMe wrote: »

What would you identify as being the configuration to properly guard against the attack?

The server requiring https of course.

ChRoMe

srsly78 wrote: »

The server requiring https of course.

The attack would still work if you re-encrypted at the proxy and sent it on....

srsly78

And how would that work exactly? Practical example please.

ChRoMe

srsly78 wrote: »

And how would that work exactly? Practical example please.

accept https connection from client, extract payload, log it, rencode as https request and proxy it on.

srsly78

No.

http://security.stackexchange.com/questions/8145/does-https-prevent-man-in-the-middle-attacks-by-proxy-server

ChRoMe

srsly78 wrote: »

No.

http://security.stackexchange.com/questions/8145/does-https-prevent-man-in-the-middle-attacks-by-proxy-server

Eh.... the caveat at the bottom of the answer demonstrates a scenario where it would work...

Khannie

ChRoMe wrote: »

accept https connection from client, extract payload, log it, rencode as https request and proxy it on.

Definitely not. If it were that simple to circumvent SSL, it would be an entirely worthless technology. To decrypt the initial exchange of session keys, you need to be trusted. If you're not (and as a proxy you would not be) then the session will bork. Now if you had physical access to the users box you could make yourself trusted. Again though, much simpler to just install a key logger at that point.

ChRoMe

Khannie wrote: »

Definitely not. If it were that simple to circumvent SSL, it would be an entirely worthless technology. To decrypt the initial exchange of session keys, you need to be trusted. If you're not (and as a proxy you would not be) then the session will bork. Now if you had physical access to the users box you could make yourself trusted. Again though, much simpler to just install a key logger at that point.

My understanding is that if you had admin on that network, forging your certs as trusted would be simple enough?

So its hardly a case of definitely not?

Edit: Also if the proxy is in place for the initial key exchange, you wouldnt even need to set your certs as trusted? (genuine question)

srsly78

No, you need admin on the client itself - not just network admin. The client must be compromised locally to make it trust the attacker/middleman certs.

As for the caveat - do you mean if the user ignores all the warnings? The warning is saying the connection cannot be trusted (because it has detected your attempted proxy shenanigans)... Maybe this should not be ignorable

As for your "initial key exchange" - these are public keys getting exchanged. Your proxy does not have either sides private key, and thus cannot masquerade as them or decrypt their info. This is the fundamental concept underlying public key cryptography -> http://en.wikipedia.org/wiki/Public-key_cryptography

Your postulated "initial key exchange attack" would work on a symmetric key system, as used since Roman times -> http://en.wikipedia.org/wiki/Symmetric-key_algorithm

ChRoMe

srsly78 wrote: »

No, you need admin on the client itself - not just network admin. The client must be compromised locally to make it trust the attacker/middleman certs.

As for the caveat - do you mean if the user ignores all the warnings? The warning is saying the connection cannot be trusted (because it has detected your attempted proxy shenanigans)... Maybe this should not be ignorable

I figured admin on the network was implicit admin on the client.

While there is an argument for not allowing the warnings to be ignorable, I think its practical for the user to make the call.

ChRoMe

srsly78 wrote: »

As for your "initial key exchange" - these are public keys getting exchanged. Your proxy does not have either sides private key, and thus cannot masquerade as them or decrypt their info. This is the fundamental concept underlying public key cryptography -> http://en.wikipedia.org/wiki/Public-key_cryptography

Client sends public key to proxy, proxy responds with its key. Takes payload and uses its public key for the exchange with the destination?

srsly78

There are signatures involved. The client will see that the signature it gets from the proxy is not the one it expects, this is how it knows the connection cannot be trusted. http://en.wikipedia.org/wiki/Digital_signature

Local admin is not the same as network admin at all! Consider the internet itself as your network, lots of people have "admin" access to your data as it travels.

ChRoMe

srsly78 wrote: »

Local admin is not the same as network admin at all! Consider the internet itself as your network, lots of people have "admin" access to your data as it travels.

No **** :rolleyes:

srsly78

So why do you find it implicit that network admin is also admin on the client?

ChRoMe

srsly78 wrote: »

So why do you find it implicit that network admin is also admin on the client?

Simply because the likely scenario we are discussing pretty much requires (i.e its possible but EXTREMELY difficult to execute otherwise) that these interactions with a proxy are happening on a local network. So generally in managed environments like that, such as AD, a network admin would also have local admin.

srsly78

In that case it isn't an attack, the client (corporate pc/device) has certs loaded for the corporate network. That's the system working as designed.

Even then, what if I used my (personal) smartphone on your corporate guest wifi? Could you decrypt my https then? (note: not a nokia or other phone that is already mitmed!!)

ChRoMe

srsly78 wrote: »

In that case it isn't an attack, the client (corporate pc/device) has certs loaded for the corporate network. That's the system working as designed.

Even then, what if I used my (personal) smartphone on your corporate guest wifi? Could you decrypt my https then? (note: not a nokia or other phone that is already mitmed!!)

Nope, but so what? Any professional network admin is not going to allow unauthorized personal devices on a network that has anything worth stealing. In fact anywhere I've worked that has anything remotely secure has a blanket ban on wifi, or there is a DMZ. The OP was right this thread has descended into nerd sniping which is getting tiresome. I've had enough.

Khannie

ChRoMe wrote: »

Client sends public key to proxy, proxy responds with its key. Takes payload and uses its public key for the exchange with the destination?

You could do that for sure and it would be easy, but it would generate a warning on the client side that the key you were receiving was not correct for the site that you were contacting.

LoLth

Vmware always warns about the certificate when conencting to the Vcenter application...no-one ever checks it, they just recognise it as "the usual" and click accept. So, in that situation, mitm would work.

I would suspect that while not everyone would read a certificate warning, enough would click "accept" or "continue to this site anyway (not recommended)" because its an annoying pop-up stopping them from getting what they want, that it is a viable threat. low hanging fruit and all that.

Wasnt there a vulnerability to do with certificate signing trees? (it allowed you to forge a certificate higher up on the authorisation tree and the "lower" cert accepted it as suthentic because of its superior breeding or something) I'll have a look and see if I can find a link....

srsly78

Not a vulnerability as such, more of a rogue Certificate Authority.