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.
Related
I have two questions about operation security of fabric.
1.In the official documentation( https://hyperledger-fabric.readthedocs.io/en/latest/operations_service.html?highlight=security#operations-security ), it says:"When TLS is enabled, a valid client certificate must be provided in order to access all resources unless explicitly noted otherwise below." Does this mean that when I access the operation RESTFUL API(e.g.GET /logspec) by curl or POSTMAN, I need to provide client certificate, right? If so, the client certificate must be generated by the corresponding organization's Fabric CA, right?
2.The documentation also says:"When clientAuthRequired is also enabled, the TLS layer will require a valid client certificate regardless of the resource being accessed.". I can't figure out what is the difference between "TLS" and "clientAuthRequired" configuration. Could any expert tell me this?
Thanks very much!
Yes ... it means that when TLS is enabled you will require a client certificate (expect where noted refers to the fact that the /healthz endpoint does not require a client certificate). The client certificate must be issued by a CA configured using the operations.tls.clientRootCAs.files property for the peer and/or the Operations.TLS.RootCAs property for the orderer.
If clientAuthRequired is enabled, then all endpoints will require a client certificate (again for now this means that /healthz would require a client cert).
I am working on a remote server that uses Netty to perform client authentication with a TLS handshake through the Netty SSLHandler library. This S/O question gives a bit: Set up Netty with 2-way SSL Handsake (client and server certificate)
Now, the question I have about this system is that the Server requires a TrustManager to initialize a SSLContext. From what I observe this uses the SunJSSE provider. Now after setting up this implementation, I got it working with RSA client certs. Now, I am having trouble using ECC client certs as SunJSSE cannot recognize them (I think Java SE 7 include SunEC as a provider. But SunEC is a SunJCE implementation and not a SunJSSE one and thus cannot be used as a provider for TrustManager). So, how do I proceed. I heard Bouncy Castle can recognize these certs, but I still cannot instantiate a TrustManager with BC as the provider.
Edit: Also if there is no way to use TrustManagers, should I do the entire handshake only use BouncyCastle's API's and not netty's libraries? That seems off though.
This is my other S/O question that shows the stack trace: Client ECC SSL Certificate contains "unknown named curve"
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.
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.
I'm trying to figure out the SSL handshake process. After reading up on TLS in Wikipedia I've seen that
The server sends its Certificate message (depending on the selected cipher suite, this may be omitted by the server)
I've also seen such behavior in real-life sniffs, but only in cases where the user eventually received an "Invalid certificate" warning.
I was wondering in which cases can a server omit the certificate? How can the client verify the server's identity in this case then? Or is it only reserved to cases where the server have no certificate and gives up on sending a fake one, knowing that the user will see a browser warning anyway?
Thanks!
Some cipher suites don't rely on certificates:
The anonymous cipher suites, defined in the main TLS RFC (the names containing DH_anon). Some of them can provide encryption, but without authentication, which is insecure. Section A.5 says the following about them:
The following cipher suites are used for completely anonymous
Diffie-Hellman communications in which neither party is
authenticated. Note that this mode is vulnerable to man-in-the-
middle attacks. Using this mode therefore is of limited use: These
cipher suites MUST NOT be used by TLS 1.2 implementations unless the
application layer has specifically requested to allow anonymous key
exchange. (Anonymous key exchange may sometimes be acceptable, for
example, to support opportunistic encryption when no set-up for
authentication is in place, or when TLS is used as part of more
complex security protocols that have other means to ensure
authentication.)
Kerberos cipher suites, in which case the identification is done via the Kerberos ticket, and the name is verified against the Kerberos principal name (host/MachineName#Realm).
Pre-Shared Keys cipher suites (see section on PSK Identity Encoding).
There is one valid case for anonymous ciphers: the opportunistic encryption of e-mail over SMTP with STARTTLS. As an MITM could easily prevent the use of TLS, there is no use in protecting agains MITM at the TLS level.
If the client knows that he will proceed anyway, even if the certificate was invalid, the can request an anonymous ciphersuite saving the server the generation of a signature and himself the verification the certificate and the signature.