SSL mutual authentication

[RebootExpert]

What is the proper way to authenticate client certificate?
Right now I have MOD54415 serve as server accepting ssl connection using the function SSL_accept();
What is not clear to me is that I set the parameter verifyPeer as true, and in my desktop console app serve as a client, the client still can establish a connection with the server without providing a client cert. Why does the server still accept the connection?
Also what is the parameter certBuff ? Is it a CA that use to check against a client certificate?

[TomNB]

Hello,

What tools version are you using? We always need to know that up front

[RebootExpert]

2.9.3

[RebootExpert]

looking in the wireshark, there's no client certificate request in server hello message during the handshake.

update:
strangely, when I reboot the module, and tried establish a tls connection with peer verify = true. This time, I did see a certificate request in the server hello of the tls handshake. There's no any firmware update, all I did just reboot. However the connection still established while the client didn't send any certificate.

[RebootExpert]

Now as my desktop applicant provide a client certificate during the handshake, the module will reject the connection request. It send a tcp FIN packet right after it receive client cert.

handshake.jpg (126.1 KiB) Viewed 8295 times

I set the parameter as follow:

Code: Select all

SSL_accept(listener, &address, NULL, 0, true, true, client_ca_cert, client_ca_cert_len, SSL_FILETYPE_PEM, <client_cert_comman_name>);

what are the correct arguments to fill in the function call?

[Jon]

Hi RebootExpert,

Taking a look, I think I see what's going on. First to answer the question about parameters:
SSL_accept(listener, &address, NULL, 0, true, true, client_ca_cert, client_ca_cert_len, SSL_FILETYPE_PEM, <client_cert_comman_name>);

The second bool is for the call to set verify peer. The client_ca_cert and client_ca_cert_len are the buffer that holds the client CA and the length of that cert, respectively. The file type is the format of the buffer (usually PEM, though we also support DER). The common name is a validation on connections to make sure the device connecting is a specific device that's allowed to (if you want to limit connections this way).

I think the fix here is to modify SslVerifyPeer() in <nndk_install>\system\cryptolib\NetBurner\NbWolfSsl.cpp.

Where it does the check for verifyPeer, replace:

Code: Select all

wolfSSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, nullptr);

with:

Code: Select all

wolfSSL_CTX_set_verify(ctx, SSL_VERIFY_PEER|SSL_VERIFY_FAIL_IF_NO_PEER_CERT, nullptr);

This will fail the connection if a certificate isn't passed in. It should probably be added to our next release as the default behavior, since that's what you would expect.

Kind Regards,
Jon

[RebootExpert]

Thanks Jon. The reason my client cert got reject because I convert a pem format of client ca cert to a cpp file using compfile. Instead I convert to der format first and compfile to cpp file. and set the parameter format to SSL_FILETYPE_ASN1 in ssl_accept();

[Jon]

Hi RebootExpert,

I'm glad to hear that you got it working, and you're more than welcome. Did you need to add the additional flag to wolfSSL_CTX_set_verify(), or did it work as is for you?

Kind Regards,
Jon

[RebootExpert]

Hi Jon,

It works perfectly. However I am not sure if it's part of the TLS standard to accept the connection without a client cert when it requests or it depend on the individual who implement it. Because I saw a note about TLS class API in microsoft document, it is class I use to build my desptop app. It state:

clientCertificateRequired
A Boolean value that specifies whether the client is asked for a certificate for authentication. Note that this is only a request -- if no certificate is provided, the server still accepts the connection request.

[Jon]

Hi RebootExpert,

It looks like, according to the RFC, it's up to the discretion of the server on whether or not to continue the connection if a cert is requested and not given:

7.4.6. Client Certificate

When this message will be sent:

This is the first message the client can send after receiving a
ServerHelloDone message. This message is only sent if the server
requests a certificate. If no suitable certificate is available,
the client MUST send a certificate message containing no
certificates. That is, the certificate_list structure has a
length of zero. If the client does not send any certificates, the
server MAY at its discretion either continue the handshake without
client authentication, or respond with a fatal handshake_failure
alert. Also, if some aspect of the certificate chain was
unacceptable (e.g., it was not signed by a known, trusted CA), the
server MAY at its discretion either continue the handshake
(considering the client unauthenticated) or send a fatal alert.

https://datatracker.ietf.org/doc/html/rfc5246#page-55

In light of this, maybe we should make it optional and up to the user to decide.

Kind Regards,
Jon