Perhaps some server can handle both non-secure and secure protocols.
Is there known way to determine if existing TCP connection secure or not?
(I believe it is possible just monitor traffic and check if some text is readable, but maybe there is better or maybe more detailed suggestions?)
If you're using .Net you can use an existing TCP connection as the basis for an SSL connection. To programatically check whether a server port implements SSL would be a matter of establishing a TCP connection and then attempting to create an SSL connection on top of it. If the SSL handshake fails, which will throw an exception, then you will know SSL is not available on that port.
The code would be along the lines of:
TcpClient tcpClient = new TcpClient();
tcpClient.Connect(remoteEndPoint);
SslStream sslStream = new SslStream(tcpClient.GetStream(), false, new RemoteCertificateValidationCallback(ValidateServerCertificate), null);
sslStream.AuthenticateAsClient(serverCN);
Exception means no SSL.
Related
A firewall is timing out TCP connections after an hour.
Sending a message along this connection from the server results in a [RST, ACK] from the firewall.
Messages sent from the client are simply dropped, as long as they are part of the original connection.
If a new connection is established from the client, it goes through the firewall without a hitch.
This is normal - routers, firewalls, VPNs, NATs, etc.., all time out connections and require you to reconnect with a new handshake or perform a TLS resume. But is there any way to continue using the TLS session without "resuming" it? I say this because the TLS session never ended, only the underlying TCP.
Because the TLS session is independent of TCP, we shouldn't need to resume an already active TLS session just because some intermediary device blocks us. Is there any type of "TCP resume" that we can do along the same socket?
This is called "session resumption" in TLS.
Quoting the latest standard on it (https://www.rfc-editor.org/rfc/rfc8446) :
Although TLS PSKs can be established out of band, PSKs can also be
established in a previous connection and then used to establish a new
connection ("session resumption" or "resuming" with a PSK). Once a
handshake has completed, the server can send the client a PSK
identity that corresponds to a unique key derived from the initial
handshake (see Section 4.6.1). The client can then use that PSK
identity in future handshakes to negotiate the use of the associated
PSK. If the server accepts the PSK, then the security context of the
new connection is cryptographically tied to the original connection
and the key derived from the initial handshake is used to bootstrap
the cryptographic state instead of a full handshake. In TLS 1.2 and
below, this functionality was provided by "session IDs" and "session
tickets" [RFC5077]. Both mechanisms are obsoleted in TLS 1.3.
See sections 2.2 and 4.6.1 of the RFC for details.
It can not be a resumption at the TCP level since the new TCP connection will need to start with a new local port (otherwise any traffic will still be caught by firewall state tracking).
SSL/TLS runs over the TCP layer. Suppose TCP connection is terminated before SSL/TLS session was closed. How would SSL/TLS get to know about this ?
A TLS session is mostly independent from the underlying TCP connections.
For example you can have multiple TCP connections all using the same TLS session and these can coexist even in parallel. This is actually used in practice, for example with web browsers. It is even required in some implementations of FTPS where the control and data connections (different TCP connections) are expected to (re)use the same TLS session. Note that the session does not simply gets continued inside another TCP connection - there is still a TLS handshake required to start the "continuation" of a session, but only an abbreviated handshake.
Similar you can have multiple TLS sessions inside a single TCP connection but only after each other: initiate one TLS session, shutdown it, initiate the next etc. While this is not commonly used it is actually not uncommon that the TLS session does only start after some plain data has been transferred (STARTTLS in SMTP, AUTH TLS in FTPS) or that TLS gets shutdown and then more data are transferred in plain (CCC in FTPS).
How would SSL/TLS get to know about this ?
The exact details depend on the TLS stack and the API provided by this stack. But usually if the underlying TCP connection is closed this is somehow signaled to the TLS stack. For example with OpenSSL a SSL_read will return a value of equal or less than 0 and you need to call SSL_get_error to get more details on what happened. And again, a TCP close does not implicitly invalidate the TLS session.
SSL/TLS runs over the TCP layer.
Correct.
Suppose TCP connection is terminated before SSL/TLS session was closed.
Then (a) the TCP connection has ended, and (b ) the SSL/TLS session persists.
How would SSL/TLS get to know about this?
It doesn't need to know about this. It only needs to know about the end of the TCP connection, which is signalled by the TLS close_notify message, and the end of the session, which happens when it is invalidated. TLS sessions can long outlive TCP connections, and vice versa.
There is a heartbeat protocol that is used by SSL/TLS to check that the connection is still alive or not. So for a heartbeat request a closed connection will response negative. Hence SSL/TLS will know that TCP connection is closed.
I'm working on adding SSL support into our existing application and have started to think about backwards compatibility.
The one special case that makes this different than other posts I've read is the server may not necessarily be updated with SSL code. So I'll have an SSL client connecting to a server that knows nothing about SSL.
For the sake of this discussion, the application sends keystrokes one at a time to the server, and for each keystroke a new socket is created. So I need to figure out a way to make this work on the existing port number and not use timeouts to determine if the server supports SSL or not.
Any suggestions on a graceful way to handle this?
(I'm using Winsock and OpenSSL)
Usually applications accept plain connections and direct SSL connections on different ports, e.g. smtp port 25 and smtps port 465, http port 80 and https port 443 etc. Other ways are to use the same port and then have a specific command from the client to upgrade to SSL, e.g. like STARTTLS with smtp or AUTH TLS with ftp.
If these common ways are not an option for you and the client sends the first packet in your protocol anyway (like with http, but not with smtp or ftp) you might do an recv(..MSG_PEEK) after the initial accept to see, what kind of data the client sends without removing the data from the socket buffer yet. If the peeked data look like your plain application protocol you continue there, if they look like a client hello from SSL (see https://security.stackexchange.com/questions/34780/checking-client-hello-for-https-classification) you do an SSL upgrade.
Let's say you want to perform an https request to a certain website but you have a proxy on the middle.
The aforesaid proxy doesn't look into the request but just relay all the traffic to the actual HTTPS server after the user-agent has used the HTTP CONNECT method (as in http://www.web-cache.com/Writings/Internet-Drafts/draft-luotonen-web-proxy-tunneling-01.txt).
Now my question is the following: after the proxy opens a SSL connection to the destination webserver, should it also upgrade the socket which handles the connection with the client to SSL as well? And if so, how would it forward packets to the server without sniffing the actual content?
What I mean here is that if the proxy actually reads data from SSL client socket and forwards them to SSL server socket, the data will be not encrypted to it.
The proxy has a plaintext connection open to the client, via which it received the CONNECT command. It opens a plaintext connection to the server. Thereafter it just copies bytes in both directions. The bytes coming from both client and server are SSL, so this works without the proxy knowing what's inside the ciphertext.
I was wondering if When using PROXY, does SSL (through HTTPS) secure the connection from the admins of the proxy, so they will not be able to see the content?
Basically, when doing SSL connections with a proxy, you connect to the proxy and use something like the CONNECT HTTP verb, which just asks the proxy to connect to the remote host on the specified port. At that point, you're not secure; you can assume that the proxy is listening to the conversation. You then start an encrypted session with the remote host, using that host's public key, or rather the remote host uses its private key which you can check against its public key without needing to trust the proxy. The handshake algorithm is such that the proxy can't see what's inside the encrypted channel (since they don't know the session keys that each side picked as part of the SSL protocol). All the proxy can do is inject random detectable noise or cause the connection to get dropped; they can do denial-of-service attacks but can't affect the integrity or secrecy of any information actually transferred.
That's the beauty of using a proper crypto protocol like SSL.