Jump to content


 


Register a free account to unlock additional features at BleepingComputer.com
Welcome to BleepingComputer, a free community where people like yourself come together to discuss and learn how to use their computers. Using the site is easy and fun. As a guest, you can browse and view the various discussions in the forums, but can not create a new topic or reply to an existing one unless you are logged in. Other benefits of registering an account are subscribing to topics and forums, creating a blog, and having no ads shown anywhere on the site.


Click here to Register a free account now! or read our Welcome Guide to learn how to use this site.

Photo

tls_rsa_with_3des_ede_cbc_sha issues


  • Please log in to reply
5 replies to this topic

#1 The_Rubb

The_Rubb

  • Members
  • 4 posts
  • OFFLINE
  •  
  • Local time:12:38 AM

Posted 26 January 2017 - 08:35 PM

Hi,

I was trying to login to my bank today, having done some small tweaks to Firefox.  It turns out that the logon page is using tls_ecdhe_rsa_with_aes_128_gcm_sha256 (receives an A from ssllabs.com), but the page I am then redirected to uses tls_rsa_with_3des_ede_cbc_sha (receives C from ssllabs.com).

 

The setting in Firefox that caused the issue was security.ssl3.rsa_des_ede3_sha - setting it to False causes "Secure Connection Failed"

 

"The connection to banking3.anz.com was interrupted while the page was loading. The page you are trying to view cannot be shown because the authenticity of the received data could not be verified."

 

Obviously this is a deprecated 112 bit cipher, and in theory shouldn't be used, but I was wondering, what is the real danger.  Are there any known attacks for this cipher, and if so, are they really a risk in terms of banking?  As the error implies the problem is my authentication of the remote server, after I have logged on using an acceptable page, is it reasonable to trust this process?  I would imagine the real risk is in compromise of the initial redirection, which could only happen server-side (in which case, my cipher selection is not the relevant factor in compromise!) based on it being done through TLS.

 

Hugo


Edited by The_Rubb, 26 January 2017 - 08:47 PM.


BC AdBot (Login to Remove)

 


#2 Didier Stevens

Didier Stevens

  • BC Advisor
  • 2,685 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:03:08 PM

Posted 28 January 2017 - 07:19 AM

I did some tests with FF and the website you gave, and there is no authentication problem.

 

The problem is the TLS handshake. My FF sends a Client Hello with the ciphers it supports, and then the server immediately closes the TCP connection with a FIN.

That is with setting security.ssl3.rsa_des_ede3_sha set to False.

So there's no Server Hello, there's actually no data coming from the server.

 

With the setting set to True, I get a TLS handshake and connection.

 

So it looks because tls_rsa_with_3des_ede_cbc_sha is not in my Client Hello, the server doesn't even attempt a Server Hello but just closes the TCP connection. This is actually reported in the first line of the FF warning:

 

 

The connection to banking3.anz.com was interrupted while the page was loading.

 

BTW, the certificate sent by the server is OK: RSA 2048 and SHA256 issued by Symantec.


Edited by Didier Stevens, 28 January 2017 - 07:20 AM.

Didier Stevens
http://blog.DidierStevens.com
http://DidierStevensLabs.com

SANS ISC Senior Handler
Microsoft MVP 2011-2016 Consumer Security, Windows Insider MVP 2016-2019
MVP_Horizontal_BlueOnly.png

 

If you send me messages, per Bleeping Computer's Forum policy, I will not engage in a conversation, but try to answer your question in the relevant forum post. If you don't want this, don't send me messages.

 

Stevens' law: "As an online security discussion grows longer, the probability of a reference to BadUSB approaches 1.0"


#3 The_Rubb

The_Rubb
  • Topic Starter

  • Members
  • 4 posts
  • OFFLINE
  •  
  • Local time:12:38 AM

Posted 29 January 2017 - 04:26 PM

Thanks for the reply.  Perhaps I should have dug a little deeper - the message is obviously a little erroneous - if it's just the server not accepting the ciphers offered, and terminating communication, then that isn't worrisome at all.

 

The second point however, was the weakness of the cipher in on the second site.  Obviously this is a deprecated 112 bit cipher, and in theory shouldn't be used, but I was wondering, what is the real danger.  Are there any known attacks for this cipher, and if so, are they really a risk in terms of banking?  Is this just a theoretical issue, and there are no known weaknesses at this time?

 

Hugo



#4 Didier Stevens

Didier Stevens

  • BC Advisor
  • 2,685 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:03:08 PM

Posted 29 January 2017 - 05:23 PM

You're welcome.

 

I don't know, I don't have a crypto background. I only know that it's weak because of 112 effective bits.


Edited by Didier Stevens, 29 January 2017 - 05:23 PM.

Didier Stevens
http://blog.DidierStevens.com
http://DidierStevensLabs.com

SANS ISC Senior Handler
Microsoft MVP 2011-2016 Consumer Security, Windows Insider MVP 2016-2019
MVP_Horizontal_BlueOnly.png

 

If you send me messages, per Bleeping Computer's Forum policy, I will not engage in a conversation, but try to answer your question in the relevant forum post. If you don't want this, don't send me messages.

 

Stevens' law: "As an online security discussion grows longer, the probability of a reference to BadUSB approaches 1.0"


#5 The_Rubb

The_Rubb
  • Topic Starter

  • Members
  • 4 posts
  • OFFLINE
  •  
  • Local time:12:38 AM

Posted 29 January 2017 - 07:53 PM

For any crypto gurus, the way I understand it, RSA is used as the public key component, which is safe enough to use.  The purpose of the RSA communication is to share the key(s) for 3DES, which is 112 bits, and not strong enough to withstand determined attack.  Is this a fair assumption?

 

If that's the case, and there is no forward secrecy, does this mean that anyone who can capture the traffic would be able to ascertain (in time) the contents of the HTTPS session?  Perhaps too difficult for MiTM, but certainly the privacy and secrecy aspect is removed for anyone able to packet capture and persist with brute force?  It looks like the time to compute this is prohibitive, so it's probably only a concern for high-value communications - am I right?


Edited by The_Rubb, 29 January 2017 - 07:57 PM.


#6 The_Rubb

The_Rubb
  • Topic Starter

  • Members
  • 4 posts
  • OFFLINE
  •  
  • Local time:12:38 AM

Posted 29 January 2017 - 08:04 PM

So, after some more reading on 3DES (https://en.wikipedia.org/wiki/Triple_DES)

 

The best attack known on keying option 1 requires around 2^32 known plaintexts, 2^113 steps, 2^90 single DES encryptions, and 2^88 memory[21] (the paper presents other tradeoffs between time and memory). This is not currently practical and NIST considers keying option 1 to be appropriate through 2030.[13] If the attacker seeks to discover any one of many cryptographic keys, there is a memory-efficient attack which will discover one of 2^28 keys, given a handful of chosen plaintexts per key and around 2^84 encryption operations.[22]

 

I guess this means that what I said is technically correct, but with current computing power, or without a breakthrough in cracking methodology, this protocol is considered "safe" for now?

 

I also see that the EMV (electronic payment industry) use this protocol extensively, so it won't be just this one bank affected.


Edited by The_Rubb, 29 January 2017 - 08:06 PM.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users