Can anyone explain to me what is pre_shared_key TLS extension and what is it relation with Session Ticket TLS extension because I observed that when the pre_shared_key extension is present in the TLS Client Hello message the Session Ticket extension is absent
... when the pre_shared_key extension is present in the TLS Client Hello message the Session Ticket extension is absent
The first one is session resumption with TLS 1.3, the second with TLS 1.2 and lower. There are several information about this protocol change on the internet, like TLS Session Resumption TLS 1.3 uses 0-RTT Handshakes.
Related
In ASP.NET Core there are 4 available certificate modes:
// Summary:
// A client certificate is not required and will not be requested from clients.
NoCertificate,
// Summary:
// A client certificate will be requested; however, authentication will not fail
// if a certificate is not provided by the client.
AllowCertificate,
// Summary:
// A client certificate will be requested, and the client must provide a valid certificate
// for authentication to succeed.
RequireCertificate,
// Summary:
// A client certificate is not required and will not be requested from clients at
// the start of the connection. It may be requested by the application later.
DelayCertificate
I want to use DelayCertificate mode because this shouldn't ask for certificate to user in e.g. web explorer, but still I can require certificate on some endpoints. But I have one consideration: It seems to me that I once read that delayed certificates aren't supported in TLS 1.3. I'm not sure about it, and I can't find the source where I read this. So what's it like with this mode? Will it work with TLS 1.3?
... I once read that delayed certificates aren't supported in TLS 1.3
In TLS 1.2 and lower renegotiation was used to ask for client certificates after the initial TLS handshake was already done. This mechanism does not exist in TLS 1.3 anymore, which means it also cannot be used for delayed client certificates anymore in TLS 1.3.
But, TLS 1.3 introduced a different mechanism for this purpose: Post-Handshake Client Authentication. Thus, delayed client certificates can still work with TLS 1.3, only differently. But it requires that the client supports it and not all might do.
Additionally TLS 1.3 post-handshake client authentication is explicitly forbidden in HTTP/2 - see RFC 8740. But similar to this delaying client certificates in response to access to a protected resource weren't allowed with TLS 1.2 in HTTP/2 either: RFC 7540 explicitly forbids renegotiation after the actual HTTP/2 protocol (inside the TLS) has been started.
Let's say my side as a client supports TLS V1.0,1.1 and 1.2.
The remote site supports TLS V1.0 and 1.1.
Both sides support the same Ciphers.
My questions:
1 - To my understanding I will always initiate the communication using the highest TLS Version I have available. In that case How will I ever be able to connect with the other side?
2 - The following is a Wireshark CLIENT HELLO capture between a client and a server described as above.
TLSv1.1 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.2 (0x0303)
Length: 172
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 168
Version: TLS 1.2 (0x0303)
Random
Session ID Length: 0
Cipher Suites Length: 52
Cipher Suites (26 suites)
Compression Methods Length: 1
Compression Methods (1 method)
Extensions Length: 75
Extension: server_name
Extension: elliptic_curves
Extension: ec_point_formats
Extension: signature_algorithms
Extension: SessionTicket TLS
Extension: renegotiation_info
This connection attempt ultimately yields a "Could not create SSL/TLS secure channel". I suspect this has something to do with what described as "TLSV1.1 Record Layer" and the "Version: TLS 1.2 (0x0303)". Could this be the reason the connection is failing?
The client starts the handshake with a ClientHello where it shows the best version it supports, i.e. TLS 1.2 in this case. The server then replies with a ServerHello with the best version the server supports which is equal or less the client offered version (i.e. TLS 1.1 in your case). If the client is not willing to accept this version (i.e. client configured to only support TLS 1.2 and nothing less) it will close the connection.
Guessing you have an an older version of Wireshark, since it reports TLSv1.1, but in the subsequent packet both the Record and the ClientHello clearly indicate TLSv1.2. Save your capture, upgrade Wireshark and then re-load the capture.
UPDATE: It's important to ensure your SSL\TLS handshake is COMPLETE; otherwise, for some reason, Wireshark will report incorrect TLS protocol version in the "protocol" field.
There are two TLS versions sent with a Client Hello message. The first is the record layer version, which describes the version of TLS that you are using to communicate. The second version is the Client Hello value, which indicates the maximum version supported by the client.
I see three TLS versions in your Wireshark capture. I think the reference to version 1.1 in "TLSv1.1 Record Layer: Handshake Protocol: Client Hello" is wrong, though.
It appears that your client is sending a Client Hello with version 1.2 indicated within a record layer version of 1.2. The server, as it does not support version 1.2, rejects at the record layer. To get around this the client could send a version 1.2 Client Hello within a version 1.0 record. This would allow the server to communicate using version 1.0 that it supports version 1.1, and subsequent communication would use version 1.1.
I am implementing an SSL Client using OpenSSL which
(1) only "speaks" TLS 1.2, TLS 1.1 and TLS 1.0,
(2) set exactly this priority: TLS 1.2. If communication is not possible, use TLS 1.1. If not, TLS 1.0. If not, refuse connection.
I achieve (1) by using
SSL_CTX_set_options(m_ssl_ctx, SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3);
But I don't know any way to achieve (2). Is there any "elegant" way to do this in OpenSSL or do I have to attempt several connections checking if communication was possible and, if not, attempt a lower protocol version?
Thanks.
There is no protocol priority setting. The client will announce the best version it can do to the server and the server will pick this or a lower version. If the version picked by the server is not supported by the client then the handshake will fail. This is not specific to OpenSSL but this is how SSL/TLS works.
Don't confuse this handshake between client and server with the TLS downgrading mechanism most browsers use. In this case browsers retry the SSL handshake on a new TCP connection with a lower version if the handshake with the better version failed. This behavior is to work around broken SSL/TLS implementations. These downgrades are mostly restricted to browsers, simpler TLS stacks are less tolerant and fail permanently if the first handshake failed.
This is closely related to
Using nxlog to ship logs in to logstash from Windows using om_ssl
Using SSL to ship from NXlog to Logstash
I have a working NXlog and Logstash configuration as described in the above links.
However, the TLS connection fails with following exception in the logstash log:
OpenSSL::SSL::SSLError: Client requested protocol SSLv3 not enabled or not supported
It seems that NXlog relies on SSLv3 instead of TLS 1.x to do the SSL handshake. However, the former has been disabled in recent Java versions (as used by logstash) due to the POODLE vulnerability.
So how can I disable SSLv3 on the client side and force NXlog to use TLS 1.2?
I have to answer this one myself (after getting help on the NXlog community forum).
TLS is only supported by nxlog-ce-2.9.1347 and later.
A client installed on jBOSS is trying to access a secured website configured on DataPower xi50v6.0.0.2 appliance. The connection is getting failed at SSL handshake.
I have taken a packet capture at DataPower and observed that SSL Handshake is failing with the Description:Handshake failure(40).
However, at the Client Hello step, I have observed that, only one Cipher Suite is specified which is : TLS_EMPTY_RENEGOTIATION_INFO_SCSV.
The TLS protocol used ( as per packet capture) is TLS1.1. Can this Cipher Suite be a problem?
In the DataPower system logs I can see below error:
Request processing failed: Connection terminated before request headers read because of the connection error occurs
Update:
The client application is running on jBOSS7.I have asked our jBOSS administrator to check the configuration at jBOSS end. I somehow got the access to server where jBOSS instance is installed and checked domain.xml where the ssl is configured. Where exactly in domain.xml, ths configuration related to cipher suites can be found?
I have observed that, only one Cipher Suite is specified which is : TLS_EMPTY_RENEGOTIATION_INFO_SCSV
This is no real cipher. If no other ciphers are specified then the client does not offer any ciphers at all which means that no shared ciphers can be found and thus the handshake will fail. It looks like the client is buggy. Reason might be a failed attempt to fight POODLE attack by disabling all SSL3.0 ciphers, which in effect disables all ciphers for TLS1 1.0 and TLS 1.1.