# Insecure third party connection

My organization processes some PII data and shares it with an outbound connection (outflow only) that is a third party. The data transfer transactions occur without human intervention. That outbound connection is encrypted using TLS 1.0 with RC4-MD5 weak hash algorithm. By industry standards TLS 1.0 is insecure. Although other controls exist such as a firewall, are there are risks pertaining to this connection with the current encryption? Please help explain what are the potential attacks that can occur. Can lease lines with socket protocols instead of web protocol be encrypted?

• Well, an attacker may be able decrypt all messages if the connection isn't renegotiated long enough and enough traffic has flown. Note: RC4 is already heavily broken and should be abandoned as soon as possible. Also see the most devastating RC4 attack to date, which can break normal cookie-based web authentication (similar attacks may apply to you): rc4nomore.com – SEJPM May 29 '16 at 9:58
• "Fun"-Fact: If you server or their server offer RC4 and / or don't immediately terminate the handshake when they see it offered, your implementation is non-compliant to the TLS standard as per RFC 7465. – SEJPM May 29 '16 at 20:16
• SEJPM - I did not know it would be non-compliant if offered and no action taken even from the client server. – user107327 May 29 '16 at 20:21
• Can lease lines with socket protocols instead of web protocol be encrypted? – user107327 May 31 '16 at 18:42

There are two facets in the use of TLS-1.0 with TLS_RSA_WITH_RC4_128_MD5. From a cryptographic point of view:

• TLS-1.0, as a protocol, is not broken. It does a number of things in a suboptimal way, forcing implementations to jump through intricate and topologically improbable hoops in order to avoid side-channel leakages. Recent implementations ought to be fine, but of course anything which is deployed is fast becoming non-recent unless it is promptly updated whenever a security fix is published by the vendor.

• RC4 has a number of weaknesses, mostly biases which are serious enough to be exploited in practice, if the usage conditions are right (for the attacker). Worst bias is on the second byte of an RC4-generated stream: that byte will have value 0x00 with probability about 1/128 instead of the expected 1/256. Thus, if you send the same secret data at the start of the stream for a few thousands of distinct streams, then the attacker will be able to guess the second byte of that secret data.

If your TLS usage really is HTTPS, then the first few dozens or hundreds of bytes of the stream will be an HTTP header, most of which being non-secret, and the data you want to protect will be subject to less serious encryption biases -- the attacker will need to observe connections by the millions, not the thousands. From an academic point of view, this is still utterly broken; but in practice, this will still be quite hard to leverage for attackers.

• MD5 is broken with regards to collisions. In TLS-1.0, MD5 is used as part of HMAC, and right now nobody knows how to attack HMAC/MD5.

From a security point of view, your use of TLS-1.0 with RC4+MD5 is thus probably not a real issue in itself. However, it is a symptom. If you still use such a protocol version and algorithms, then chances are very high that your implementation is an old library which has not been updated in the last decade, thus probably riddled with numerous known vulnerabilities that would allow attackers to simply buffer-overflow it to death. Real-world attackers don't resort to breaking cryptography upfront unless they have no other choice.

Therefore, while using TLS-1.0 with RC4+MD5 is not an immediate danger, it indicates that there are very serious structural issues in your software management procedures, namely that they don't exist. This is what you should strive to fix.

Also, if you handle PII, then chances are that you must comply to some regulations. If conformance auditors see you using TLS-1.0, RC4 or MD5, then they will skin you alive.

• Can lease lines with socket protocols instead of web protocol be encrypted? – user107327 May 31 '16 at 18:42
• TLS is based on TCP, which is a "socket protocol". HTTPS is just TLS with an HTTP connection on top of it. – Maarten Bodewes May 31 '16 at 20:26
• TLS is actually defined to work over any bidirectional stream of bytes, not necessarily a TCP connection (this is the main official reason of the rename SSL -> TLS when the IETF took charge of the protocol). It can be used over a serial line, or anything that transfer bytes. Some protocols (e.g. EAP) even rechop TLS exchanges into individual messages. – Thomas Pornin May 31 '16 at 21:22