From a567dca5ea418a0aaaed8fb4359032b11f28cccd Mon Sep 17 00:00:00 2001 From: Magnus Henoch Date: Fri, 29 Jan 2016 18:47:43 +0000 Subject: ssl: with verify_none, accept critical extensions When establishing a TLS connection with {verify, verify_none}, if the server has a certificate with a critical extension, for example a "Netscape Cert Type" extension, certificate verification would fail, which is surprising given that the name of the option suggests that no verification would be performed. With this change, certificate extensions marked as critical are ignored when using verify_none. --- lib/ssl/src/ssl.erl | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'lib/ssl/src') diff --git a/lib/ssl/src/ssl.erl b/lib/ssl/src/ssl.erl index 6551308935..401ee63908 100644 --- a/lib/ssl/src/ssl.erl +++ b/lib/ssl/src/ssl.erl @@ -1280,6 +1280,12 @@ handle_verify_options(Opts, CaCerts) -> DefaultVerifyNoneFun = {fun(_,{bad_cert, _}, UserState) -> {valid, UserState}; + (_,{extension, #'Extension'{critical = true}}, UserState) -> + %% This extension is marked as critical, so + %% certificate verification should fail if we don't + %% understand the extension. However, this is + %% `verify_none', so let's accept it anyway. + {valid, UserState}; (_,{extension, _}, UserState) -> {unknown, UserState}; (_, valid, UserState) -> -- cgit v1.2.3 From 331afa5dfaa129a5ea41af5dd76246bb922ac7df Mon Sep 17 00:00:00 2001 From: Magnus Henoch Date: Fri, 22 Jan 2016 12:31:36 +0000 Subject: Be suspicious of certificates without CRL DPs Previously, if certificate revocation checking was turned on, and a certificate didn't contain a CRL Distribution Points extension, and there was no relevant CRL in the cache, then ssl_handshake:crl_check would accept the certificate even if the crl_check option was set to reject certificates for which the revocation status could not be determined. With this change, such certificates will only be accepted if the crl_check option was set to best_effort. The process for CRL validation is described in section 6.3 of RFC 5280. The text doesn't mention any special treatment to be given to certificates without distribution points: it just says "For each distribution point..." (section 6.3.3), which would leave the revocation status undetermined, unless there were "any available CRLs not specified in a distribution point but issued by the certificate issuer". Thus the result of this algorithm should be UNDETERMINED in this case, not UNREVOKED, and the crl_check option should govern how the implementation reacts to this result. --- lib/ssl/src/ssl_handshake.erl | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) (limited to 'lib/ssl/src') diff --git a/lib/ssl/src/ssl_handshake.erl b/lib/ssl/src/ssl_handshake.erl index e9e140836b..e98073080a 100644 --- a/lib/ssl/src/ssl_handshake.erl +++ b/lib/ssl/src/ssl_handshake.erl @@ -2072,12 +2072,9 @@ crl_check(OtpCert, Check, CertDbHandle, CertDbRef, {Callback, CRLDbHandle}, _) - ], case dps_and_crls(OtpCert, Callback, CRLDbHandle, ext) of no_dps -> - case dps_and_crls(OtpCert, Callback, CRLDbHandle, same_issuer) of - [] -> - valid; %% No relevant CRL existed - DpsAndCRls -> - crl_check_same_issuer(OtpCert, Check, DpsAndCRls, Options) - end; + crl_check_same_issuer(OtpCert, Check, + dps_and_crls(OtpCert, Callback, CRLDbHandle, same_issuer), + Options); DpsAndCRLs -> %% This DP list may be empty if relevant CRLs existed %% but could not be retrived, will result in {bad_cert, revocation_status_undetermined} case public_key:pkix_crls_validate(OtpCert, DpsAndCRLs, Options) of -- cgit v1.2.3