Any way to detect if a remote website supports SPDY and what version it is?
Something I can use from the command line like a bash script.
Tried sending custom User-Agent headers with curl but can't get any kind of response headers that would help me.
The idea is to be able to get SPDY:true/false Version:3.1/3.0... for any domain.
openssl s_client -connect google.com:443 -nextprotoneg ''
CONNECTED(00000003)
Protocols advertised by server: spdy/3.1, spdy/3, http/1.1
The SPDY protocol negotiation happens during the initial TLS handshake.
There are currently two ways to negotiate the protocol: the older one is called NPN (https://datatracker.ietf.org/doc/html/draft-agl-tls-nextprotoneg-04).
In the ClientHello TLS message the client sends the NPN extension with ID 0x3374. The server replies with a ServerHello TLS message that also contains the list of protocols supported by the server also in a NPN extension.
The client then chooses the protocol and sends its choice, encrypted, to the server.
The newer method has been designed for HTTP 2.0 and is called ALPN (https://datatracker.ietf.org/doc/html/draft-ietf-tls-applayerprotoneg-05).
The ClientHello TLS message contains the ALPN extension with ID 0x10.
The client, this time, sends the list of protocols supported and the server replies with a ServerHello TLS message that contains the protocol chosen by the server, also in a ALPN extension.
In both the NPN and ALPN extension the list of protocols is sent as strings such as http/1.1 or spdy/3.
Once the protocol has been chosen, the TLS handshake continues and then both parties will start to speak immediately the protocol that they have chosen.
The only way to be aware of negotiation of the protocol is therefore to use TLS and to have a client that exposes the protocol negotiation extensions.
Each client does that in a specific way, but there is not yet support for bash scripts, as far as I know.
HAProxy for example has support for both NPN and ALPN (http://cbonte.github.io/haproxy-dconv/configuration-1.5.html) and Jetty 9.2 too has support for both NPN and ALPN (both for clients and servers).
Other servers like Nginx or Apache have support for NPN with patches for ALPN (since it will be needed by HTTP 2.0 anyway).
NPN will eventually fade away; Google's Adam Langley has stated that NPN will be deprecated in favour of ALPN.
Related
I have a nodejs based web app that uses http2 library of nodejs. I start my app
HTTP/2 server is listening on port 3000. PID: 238718.
and want to check app's homepage: http://localhost:3000/
I have an error in Chrome browser: ERR_INVALID_HTTP_RESPONSE
I know that Chrome uses HTTP/2 over TLS (HTTPS).
Does any possibility exist to use HTTP/2 w/o HTTPS in a browsers?
Does HTTP/2 require encryption?
No. After extensive discussion, the Working Group did not have consensus to require the use of encryption (e.g., TLS) for the new protocol.
However, some implementations have stated that they will only support HTTP/2 when it is used over an encrypted connection, and currently no browser supports HTTP/2 unencrypted.
Source: https://http2.github.io/faq/#does-http2-require-encryption
Note that you can just use a self signed certificate for local development
I have a question about SSL. As I know, when we use browser to request from https server, it will make an SSL handshake first then all data will be encryption in the connection. But if I make a request without browser (like request module in nodejs, postman...), will it be an SSL handshake and data encryption on the connection?
Anyone know please explain to me, thank you.
First, stop saying SSL. Its successor is TLS, and it will have 20 years next January.
TLS is a protocol sitting on top of TCP typically (other variants can also use UDP), and provides on top of TCP features some new features about endpoints authentication and transport confidentiality and integrity.
In a way, you can understand it as being sandwiched between TCP and the higher level application protocol, like HTTP.
Saying otherwise you can use many others protocols on top of TLS: you have all email related ones (SMTP, IMAP, POP, etc.), you can have FTP on top of it (while probably not a good idea nowadays), XMPP for realtime communications, etc.
In short, any protocol using TCP could use TLS with some adaptation.
So HTTP is one case among others. HTTP is between an HTTP client and an HTTP server, or webserver for short.
A browser is an HTTP client. One among many ones. When you use curl or wget you are also an HTTP client. So if any HTTP client access an http:// link it will first do the TLS handshake, after the TCP connection and before starting to do anything really related to the HTTP protocol.
You have specialized libraries dealing with TLS so that not all program need to recode everything about this again, since it is also complicated.
I am currently implementing OpenSSL's TLS/SSL standards into my mail service, allowing my users to select the TLS/SSL version they want. Here is the list of versions:
["TLSv1","TLSv1_server","TLSv1_client","SSLv3","SSLv3_server","SSLv3_client","SSLv23","SSLv23_server","SSLv23_client","TLS","TLSv1_1_server","TLSv1_1_client","TLSv1_1","TLSv1_2","TLSv1_2_server","TLSv1_2_client"]
I did some Googling on what the difference of the options are, and I understand that some versions are deprecated, or shouldn't be used because of security issues, such as TLSv1. I don't understand the difference between the client vs server ones, but from my own testing, the server options return errors when trying to send a mail with it.
So my question is - of that list, what should I remove?
What you show are not SSL/TLS versions but various types of SSL contexts which also include the usable SSL/TLS versions. This means the *_server "versions" are all SSL contexts which should be used on the server side where you usually also need a certificate. The *_client variants are for the client side of the TLS handshake, i.e. the one which initiates the TLS handshake.
Within a mail client you don't want to use any server specific SSL contexts because with these the mail client would expect the peer to start with the TLS handshake which it does not.
For more details see the man page of SSL_CTX_new which has a detailed description of what all these different contexts mean.
... allowing my users to select the TLS/SSL version they want.
While your specific implementation is wrong the idea of letting users chose the protocol version is wrong too. Instead you should just use a generic context without limitations (apart from disabling insecure versions) so that it automatically picks the best protocol version during the TLS exchange. Selecting specific protocol versions should only be done in case the peers TLS stack is broken, like for stacks which simply refuse a TLS 1.2 handshake instead of replying with TLS 1.0 in case they don't support TLS 1.2.
I am currently seeing a vulneribility post scanning for Downgrade Prevention Attack on my website, I did a quick check on google and figured out TLS Fallback Signaling Cipher Suite Value (SCSV) can be used for Preventing Protocol Downgrade Attacks,
But can anyone suggest what changes will i have to make to my IBM HTTP server conf files to prevent this vulneribilty. If not how can we implement TLS Fallback Signaling Cipher Suite Value (SCSV)
djrecker.
IHS doesn't support SCSV, which is a protocol that enables browsers to do slightly less unsafe non-TLS negotiation when they see connections abruptly closed.
You could disable SSLv3 so there is no "weak" protocol to allow this to downgrade to.
We've been having issues getting a successful SSL connection from a client app trying to connect using wininet on windows xp sp3 (ie v6). The client hello looks off to me, why would the hello state its version as SSL 2.0 and then state the handshake version as SSL 3.0? Is there something coded incorrectly from the app using wininet?
SSLv2 Record Layer: Client Hello
[Version: SSL 2.0 (0x0002)] <---------------------
Length: 76
Handshake Message Type: Client Hello (1)
Version: SSL 3.0 (0x0300) <---------------------
Cipher Spec Length: 51
Session ID Length: 0
Challenge Length: 16
Cipher Specs (17 specs)
Challenge
SSLv3 and TLSv1.x have a compatibility mode in case the client also supports v2 servers, as described in the TLS specification (Backward Compatibility With SSL).
Some clients support this. For example Oracle/Sun Java has an SSLv2Hello pseudo-protocol, which uses SSLv2 Hello, but doesn't actually support SSLv2.
I know this issue is solved but I will share some more info about the subject which may be useful for viewers
"The client sends a SSLv2 ClientHello so that a server who understands only SSLv2 can process that message, and continue with a SSLv2 handshake. But the SSLv2 ClientHello also says "by the way, I know SSLv3, so if you know SSLv3 too, let's do SSLv3 instead of SSLv2", which is what usually happens (servers who know only of SSLv2 are extremely rare nowadays)."
I took it from Thomas Pornin's comment, link
https://security.stackexchange.com/questions/34827/why-clients-offer-handshaking-with-ssl-2-0-protocol