What are the vulnerable areas when two endpoint connect via TLS? Does the physical layer or data link layer a factor of security concern between the two endpoints? Does it matter in terms of security, that some portion of the link between the two is wireless?
-
Related: [How is it possible that people observing an HTTPS connection being established wouldn't know how to decrypt it?](http://security.stackexchange.com/questions/6290/how-is-it-possible-that-people-observing-an-https-connection-being-established-w) – Hendrik Brummermann Dec 20 '12 at 21:40
2 Answers
The actual physical layer or data link layer do not present a security concern as long as you force mutual authentication and use a properly secure ciphersuite.
There is no direct risk with physical layer access. There is a future risk with it.
As somebody with access to the physical layer or data link layer has the possibility to store all traffic indefinitely, they can use future techniques and processing power to crack the current connection. If the data you transferred is only relevant in the now, no issue there. But keep that in mind when selecting a proper ciphersuite to use and determining the size of your certificate keys.
The security in your connection also relies on the certificates used and their trust-root. So the CA that is used for authenticating both sides is a security issue, as somebody able to compromise the CA can possibly also listen in on or manipulate future connection and/or spoof endpoints.
- 386
- 1
- 4
-
1The last paragraph seems to be a bit ambiguous so I'll add a bit of detail. If someone compromises the CA, your historical communications are not suddenly able to be decrypted. What @Paul meant (I assume) was that if a CA is breached, it is possible that they can create a trusted certificate with almost any parameters, and therefore impersonate one of the two endpoints and perform a Man-in-the-Middle attack. Again, they cannot get your private key from breaching a CA; that is not information you (should) give to anyone. – JZeolla Dec 20 '12 at 13:07
SSL/TLS has been designed to provide security regardless of the transport medium. See the first paragraph of appendix F:
The TLS protocol is designed to establish a secure connection between a client and a server communicating over an insecure channel. This document makes several traditional assumptions, including that attackers have substantial computational resources and cannot obtain secret information from sources outside the protocol. Attackers are assumed to have the ability to capture, modify, delete, replay, and otherwise tamper with messages sent over the communication channel.
SSL still makes the assumption that the medium provides integrity under non-hostile conditions. Indeed, SSL provides integrity by reliably detecting alterations (be they malicious or not); however, once an alteration is detected, the connection is dropped, there is no recovery. This strategy works in practice because SSL is usually operated over TCP, and TCP includes recovery features: packets can be received out of order, duplicates are dropped, unacknowledged packets are reemitted, and checksums detect most transmission errors. This leaves to the SSL layer only wanton modifications; since the attacker who can modify the data can also cut the cable altogether, detection of malicious alterations is deemed enough.
If the transport medium does not provide TCP-like integrity, then SSL is not practical. Its security would not be questioned; but many connections would be dropped, implying a big usability issue.
- 322,884
- 58
- 787
- 955