Certificate subject match validation

[George-Theodor Serbana]

> I am writing a SSL/TLS client (using Boost.Beast but underlying it's using
> OpenSSL) and although I have set on the SSL context the 'verify_peer'
flag,
> there is no verification to prove the server presents an X509 which
> contains in the Subject Alternative Names the hostname of that server.
>
> As this is probably the dumbest type of attack someone could do (using a
> valid certificate with another domain name), I am thinking I'm doing
> something wrong. But from the documentation, I saw that using
"verify_peer"
> should perform all the verifications...

It verifies the trust chain.  To also verify the peer name, you need to
specify the peer name via:

    SSL_set1_host()

> Now if not even this simple check is being done, how about expiration of
> the certificate, revocation status and other checks? Should they be
> performed manually as well?

No, that's what VERIFY_PEER is for.

> For now I am using X509_VERIFY_PARAM_set1_host with SSL_CTX_set1_param to
> do this specific check.

That's the slightly less convenient legacy API from OpenSSL 1.0.2.
In 1.1.0 and later, you can use SSL_set1_host() (and in some
cases also SSL_add1_host()).

See the SSL_set1_host(3) manpage for details.

---------------------------


Indeed I re-read the docs and it says that users should not assume that
hostnames are validated by default without explicitly calling the API, I
must've missed that bit and thank you for letting me know. I will shift
towards using the newer SSL_set1_host together with some flags (I don't
want any wildcards).

Now just to be extra safe I'm still asking: will the VERIFY_PEER option
together with SSL_set1_host instruct OpenSSL to perform all possible checks
on the certificate presented by the server such that no security breach
remains at this level? Is there anything else that I should call or perform
manually?

-- Theodor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20200328/77a140c0/attachment.html>