What happens on the wire when a TLS / LDAP or TLS / HTTP connection is set up?
I'm rewording my question so hopefully I can get a better response. I asked a similar question on serverfault here, and think that a proper and valid TLS server is one that expects the "STARTTLS" command.
Is it true that STARTTLS can be issued to a properly configured LDAP or HTTP TLS server without needing an extra port? I know that this is true from an SMTP perspective, but aren't sure how broadly I can apply those experiences to other protocols.
I've spent time reading (but not fully grasping)
- The TLS Spec
- Differences between TLS and SSL
- The SSL Spec
Q: What happens on the wire right before the TLS over LDAP or HTTP session is set up? Since this is TCP based can I simply telnet to that port and issue some command to verify it's working (up to that point)?
Solution 1:
There are very few differences between SSL and TLS in the way they are used. There is, however, a fundamental difference between up-front establishment of SSL/TLS and the use of a command such as STARTTLS. Sometimes, "TLS" is used in contrast to "SSL", to mean "using a STARTTLS mode" but this is incorrect.
Up-front TLS/SSL
In this case, the client initiates the TLS/SSL connection before anything else, so SSL/TLS handshake happens first. Once the secure socket is up, the application using it can start sending the various commands for the protocol above TLS (e.g. HTTP, LDAP in this mode, SMTP).
In this mode, the SSL/TLS versions have to run on a different port from their plain counterparts, for example: HTTPS on port 443, LDAPS on port 636, IMAPS on port 993, instead of 80, 389, 143 respectively.
The layers implementing these application protocols barely need to know they're running on top of TLS/SSL. Sometimes, they're simply tunneled in tools such as sslwrap.
TLS after STARTTLS (or equivalent)
The TLS specification allows for the handshake to happen at any time, including after having exchanged some data in plain TCP over the same TCP connection.
Some protocols, including LDAP, incorporate a command to tell the application protocol there will be an upgrade. Essentially, the first part of the LDAP communication happens in plain text, then a STARTTLS message is sent (still in plain text), which indicates that the current TCP connection will be reused but that the next commands will be wrapped within a TLS/SSL layer. At this stage, the TLS/SSL handshake happens and the communication is "upgraded" to TLS/SSL. Only after this the communication is secured via TLS/SSL, and both the client and servers know that they have to wrap/unwrap their commands from the TLS layer (typically adding a TLS library between the TCP layer and the application layer).
The details of how STARTTLS is implemented within each protocol vary depending on the protocol (because this has to be compatible with the protocol using it to some extent).
Even HTTP has a variant using this mechanism, although it's mostly never supported: RFC 2817 Upgrading to TLS Within HTTP/1.1. This is completely different from the way HTTPS works (RFC 2818), which initiates TLS/SSL first.
The advantages of the STARTTLS approach is that you can run both secured and plain variants on the same port, the disadvantages are the consequences of that, in particular potential downgrade attacks or possible mistakes in the configuration.
(EDIT: I've removed an incorrect sentence, as @GregS pointed out, thanks.)
(EDIT: I've also put more on SSL vs. TLS in this answer on ServerFault.)
Solution 2:
The "STARTTLS command" is something that's defined outside the TLS spec. It's what a client sends to a server on a previously unencrypted connection to say "Ok, lets start a TLS negotiation now".
Not all protocols implement such a command. SMTP does, but HTTP and LDAP (as far as I'm aware) do not.
When an explicit command to begin TLS is not present, the usual alternative is to designate a specific port: like 443 for HTTP(s) and 636 for LDAP(s). In that case, the TLS negotiation begins as soon as the TCP connection is established.
A good tool for troubleshooting that is the "s_client" tool in openssl. For example:
openssl s_client -connect ldap.mycompany.com:636
will connect and dump out the server's certificate. Think of it as being like "Telnet" for a TLS connection. (Of course, LDAP is not a text-based protocol, so you can't do anything useful from the keyboard once the TLS connection is established.)
Solution 3:
LDAP uses an extended operation to initiate installation of the TLS layer. See also section 4.14 in the RFC.