I understand that the server will send its SSH version and the client will do the same. What I am wonder is if the order matters.
Additionally, I'm wondering if I could make an SSH server receive an SSH version from a client before sending its own version?
The order of the SSH protocol version exchange is unspecified; it says:
When the connection has been established, both sides MUST send an
identification string. This identification string MUST be
SSH-protoversion-softwareversion SP comments CR LF
The RFC is likely silent on the protocol version exchange order because, practically speaking, it's a race and the order should not matter. When the client's TCP connect is accepted by the server, the client and server send their version information...who gets to the other first is just a matter of speed, traffic, etc.
As a client, you cannot (or should not be able to...) "make" the server wait; it's certainly possible that a particular server implementation waits for client before sending its own information but that's a server implementation detail.
You can Wireshark the SSH connection and see the communication at the TCP level. The SSH client will send its Protocol version first before the server.
I don't think you have the flexibility to change the order of communication. With my SSH client (OpenSSH_8.1p1, LibreSSL 2.7.3) I could see that once SYN-ACK is done, the server is waiting for the SSH client to send it's supported protocol version.
You cannot change the order of the protocol in this case; it's fixed in the RFC, and the order does indeed matter. The server sends its version as part of the opening request, and then the client sends its version. Afterward, the two sides exchange a list of algorithms supported by both sides, and the selected algorithm is generally the first one the client supports that's also supported by the server.
While you cannot change the protocol version number announcement, you can, based on the version that the client has sent, choose to offer different algorithms. For example, some versions of OpenSSH incorrectly implemented curve25519-sha256#libssh.org, so a server which knows about this may choose not to offer that algorithm to a broken version of OpenSSH. Similarly, the client can announce different algorithms to the server based on the server's version announcement.
Related
I've recently been passed an embedded project where an MCU uses libwebsockets (version 3.1.0) to setup a websockets client. The MCU is connected to a SIMCOM modem for 4g connectivity.
Up until now the communication was non-secured: SSL context not set and modem configured to provide just a TCP link to the server. The server URI was a wss one, but security was not enforced.
I've now been asked to set the communication to use SSL/TLS with server and client authentication.
Having never used libwebsockets before and being short on time, my idea was to:
a) Leave libwebsockets set as it was, so with no SSL context set up.
b) Configure the modem to creat an SSL/TLS context and connect to the server through that one.
I did this and I can see my device sending the request to switch from http to websockets protocol, as well as the server's successful reply (code 101). But my problem is that the server's reply never gets processed by libwebsockets and the connection is dropped after a few seconds.
I can se3 that the bytes that make up the server's reply are received by the modem and passed into the MCU's buffer used to pass data into libwebsockets, but then the library never calls its net_recv method to actually read from such buffer.
Also, libwebsockets is currently built with TLS support and uses mbedTLS as SSL/TLS library. But, as said about, SSL context is currently left disabled (ssl_connection in the connection info struct is left set to 0).
So, I was wondering:
Is my approach something that can work at all? Or should I setup the SSL context from libwebsockets and let the modem setup just a TCP connection?
If I were to setup the SSL context from libwebsockets, is there a way to pass certificates and keys tot the library as just C arrays? Or do I have to have them stored as files on a filesystem and then pass their paths to the lib?
Also, I should add that the MCU has a second connection to the server, an HTTPS one, that one too setup with client and server authentication and that works with no problems at all. Therfore, I'm sure that the modem is correctly configured.
If needed, I will be able to provide more info on library configuration and used from Monday, because I'm currently travelling and don't have access to the code. But I wanted to get the ball rolling.
Thanks in advance for your help.
Yesterday, finally I had time to look at the code again. It turns out that the problem was in my code (this was always a strong possibility).
The local implementation of the net_send had a bug and returned always negative values. Thus, libwebsockets thought that the HTTP request to switch protocol had failed and hence was closing down the connection.
So, to answer the two questions above:
Yes, it's possible to setup libwebsockets to not handle SSL/TLS and then provide a SSL/TLS connection from a lower layer (the modem in my case).
It is possible to store certificates and keys in C arrays of bytes and pass them to libwebsockets if you create a custom platform implementation for your platform and create a custom implementation of POSIX like methods (open, close, read, etc).
By default the library expects to work on a POSIX like filesystem, though. So, realising a custom implementation can be a bit of a job.
The above is true for libwebsockets version 3.1.0. I haven't used any other version of the library, so things might have changed since then.
All in all, I think that configuring libwebsockets to handle SSL and the TLS handshake and then provide it with only a TCP connection is the best way of using the library.
I chose a different strategy for the wrong reasons (tight deadline + not being familiar with the codebase), but I'm definitely planning on reviewing my approach at a later date.
Suppose I am sending "hello" to an api over ssl. My understanding is there would be a symmetric key exchange established over ssl and then the message "hello" will be encrypted using that symmetric key and sent over to the other server.
Now my question is, the next time I send a "hello 2", does the symmetric key exchange happen again? My guess would be that if it's a persistent connection, there would be no need for the key exchange again. Can someone confirm?
Meta: this doesn't appear to me to be programming, although it might be development and is mostly dupe How long does SSL connection between a client and a server persist? .
It depends on the application protocol used on top of SSL (which since 1999 is really TLS, although many things e.g. implementation classes still use the old name) and usually the implementations at both ends. For example, HTTP/1.1 defaults to connection persistence (which was often done in 1.0 as an extension called keep-alive), but either endpoint can change this by specifying connection: close, and even if the connection is kept open can choose to close it anytime later, perhaps after a minute or two, perhaps after a day or a week. The HTTPS implementation in browsers usually keeps connections open for a little while but has limits on the total connections open so those that haven't been used recently may need to be closed when others are opened. Other applications, libraries, and platforms vary. Other protocols also vary; for example an email agent using SMTPS would normally make a connection, transmit one or more emails, and then disconnect.
In addition, SSL-now-TLS through 1.2 supports session resumption, which allows the keyexchange (and other handshake results) performed on one connection to be saved (at both endpoints, or with the 'ticket' option, at client only) and reused on a new connection, for as long as the endpoint(s) agree; implementations usually call this session caching. See e.g. RFC 5246 section 7.3 specifically the part starting in the middle of page 36, and for one fairly common server (Apache) see SessionCache and SessionCacheTimeout directives. Resumption uses a new handshake but not a full keyexchange on that handshake.
However, this creates a security vulnerability if an endpoint's sesssion cache is compromised, so TLS 1.3 replaces it with a different method using dynamically created PSKs; see RFC 8446 section 2.2. This allows either a partial handshake (doing the actual keyexchange with [EC]DHE but authentication tied to the previous session by the PSK rather than full certificate-based authentication) which provides forward secrecy, or a minimal handshake (using the PSK both as the new initial secret and for authentication) which does not.
If you want an answer for specific software, and specific server(s), you need to look at the capabilities and configuration, and often also the current status, of that software and those server(s).
We use a provider of global TURN servers (Xirsys). When establishing a connection between peers, each peer first identifies the closest TURN server to their location, then fetches credentials for that server. The peers then exchange ICE candidates, including their respective TURN server URLs.
If those peers are in different regions, they will propose different TURN servers. According to the accepted answer to this question: TURN-Server for RTCConfiguration the respective TURN servers will connect to each other to relay streams from Peer1 <> TURN1 <> TURN2 <> Peer2. However, I have been unable to get this to work. Forcing TURN in the clients (i.e. no direct p2p connections), and attempting to establish a peerConnection using a TURN server in e.g. the United States to one in Brazil, negotiation always fails.
Is this because the servers require credentials that are not passed in the ICE candidates? Or perhaps it's a Xirsys-specific problem? Or should it actually work fine and we're doing something else wrong?
No it's not going to be because of the credentials. They are used between the client and its TURN server. The connection between the TURN server and remote end point doesn't use any authentication.
In fact each TURN server should be blissfully unaware that the remote party is even another TURN server. As far as they are concerned they forward packets to the remote end point just the same no matter whether it's a browser, another TURN server or some other application.
So, while working through two TURN servers is possible, it's definitely not easy. The reason is that the first TURN server will generate an allocation with a given port. The second TURN server will need to send data to this port. However, how does the first TURN server know where to send that data? The second TURN server will not yet have an allocation!
Typically, WebRTC applications use a singular TURN server. If you want to use two, it means having control of the allocation generation and massaging of the SDP.
I would like to display a message to customers who's browser's highest level of encryption is SSLv3. Is it possible for me to target browser settings of SSLv3 and lower? Client or Server code? We will be allowing lower versions of SSL to use our site during a certain grace period. During this grace period, we would like to display a message only to those users that have browser settings of SSL3 or lower.
Not easily. The browser's supported SSL versions are not detectable until the SSL handshake is in progress, and even then only if the browser uses an SSLv2 handshake to allow dynamic version negotiation. If an unsupported version were detected, you would not be able to send a message back since the handshake failed and the connection would be closed before you could send any message. However, SSL itself has an error packet that gets sent during handshaking, and it can specify a version mismatch error.
The best you can do in your own code is support all SSL versions on the server side, let the client complete a handshake normally, and then detect which version was actually used and send back a message if the SSL version is too low.
Or, you could simply enable TLSv1 or higher only, and simply refuse to let older clients connect at all. They just would not get a nice error message unless the browser decided to detect the SSL version mismatch error and display its own pretty message about it.
Firstly, nowadays, you can generally forget about clients that don't support at least SSLv3. SSLv3 has been widely available for many years.
The TLS Client Hello message, sent when the connection is initiated by the browser, should contain the highest TLS version it supports:
client_version
The version of the TLS protocol by which the client wishes to
communicate during this session. This SHOULD be the latest
(highest valued) version supported by the client. For this
version of the specification, the version will be 3.3 (see
Appendix E for details about backward compatibility).
Appendix E is of course worth looking at.
(The Client Hello message will also contain the list of cipher suites the client supports, which is possibly relevant for the general idea of your question.)
Of course, this specification is just a "SHOULD", so a client supporting TLS 1.2 could still send a Client Hello for TLS 1.1, but what would be the point? By doing so it would have no chance ever to use TLS 1.2 anyway. It could be a preference box that is turned off, but that would effectively make it a client that doesn't support the highest version anyway. (If you want anything more subtle, you'd need to build a database of known user agents, which will be partly unreliable, and for which you'd need to analyse the full user agent string to know everything possible about the platform.)
Now, how to convey the content of the Client Hello message to your application is another matter, and depends very much on which SSL/TLS stack you use. It might not even be directly possible without modifying that SSL/TLS library or the server you're using.
This being said, you can generally get the negotiated TLS version during the current session quite easily. Since that version is the "lower of that suggested by the client in the client hello and the highest supported by the server" (i.e. "min(max(client), max(server))"). If your server supports SSLv3, TLS 1.0, TLS 1.1 and TLS 1.2, and since the latest version is TLS 1.2 anyway, what you'll get during your current connection will also be the max currently supported by the client. As long as your server supports the latest version, you should be able to know what the client supports at best from any live connection.
If you're behind Apache HTTP server's mod_ssl, you should be able to get that from the SSL_PROTOCOL environment variable. You should also be able to get the protocol from the SSLSession in Java.
(If you are willing to write a more bespoke service, you could pass further details like the cipher suites more directly to your application, like this service from Qualys SSL Labs does, although I'm not sure if it's meant to be widely available or just a test service.)
I'd have to agree with Remy about it being a bit challenging.
However, a good starting point may be to retrieve some SSL (certificate) information.
Something similar to this:
X509Certificate certChain[] =
(X509Certificate[]) req.getAttribute("javax.net.ssl.peer_certificates");
Another way of getting more information is to retrieve the cipher_suite attribute (similar to the code snippet above).
javax.net.ssl.cipher_suite
I hope this (at least) gets you closer.
Good luck.
In the SSH transport layer protocol specification, http://www.ietf.org/rfc/rfc4253.txt, section "4.2. Protocol Version Exchange", it says, "When the connection has been established, both sides MUST send an identification string.".
but it doesn't define which side shall initiate this process, the server side or the client side?
here are some observations,
In http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_12-4/124_ssh.html, "Figure 2: SSH Transport Layer Protocol Packet Exchanges", the client side initiate the exchange process.
I tried using JSCH as client to connect server, and here is the snapshot. the server side send the SSH Protocol version first.
And here is one issue, both JSCH and SSH server doesn't send Protocol version.
The TCP connection is setup in package 93, 94, 95. And after 5 seconds, the server side close the connection in package 99.
can you help figure out why both client and server doesn't send out the protocol version? thanks a lot!
Regards,
Joey
Yes, we had found that some cisco box does not send its version string
without receiving the client's version string.
The recent jsch version will send it immediately.
but it doesn't define which side shall initiate this process, the server side or the client side?
Correct. As both sides must send it, and neither is defined as a response to the other, it is irrelevant who does so first.