Please sign in to comment.
Workarounds for missing curves in OpenSSL
In case where the OpenSSL version used cannot successfully do openssl s_client connects there are a few problems, see #1087. This PR partly addresses them by * changing the logic of HTTP header failure: we don't terminate anymore but continue with a warning message * we try to find out what the reason was: If it is a missing curve we signal it back to the user * we keep track in a global variable KNOWN_OSSL_PROB. It's not being used yet on all connects as it has not been decided whether we do a connect despite we know if there's a problem or rather not. * Give hints to the user for resumption tests, secure renegotiation, CRIME and BREACH. For the latter --assume-http needs to be supplied for any output. Also: for finding the OPTIMAL_PROTO now (unless --ssl-native is being used) sockets are the default which removes in cases where an openssl s_client connect fails, the initial message 'doesn't seem to be a TLS/SSL enabled server' and prompt 'Really proceed ? ("yes" to continue)'. For STARTTLS this needs to be done as well. Here a minor bug was fixed: when openssl s_client connect in determine_optimal_proto() succeeded without a protocol supplied, OPTIMAL_PROTO wasn't set. A statement was added but now it is only being used when --ssl-native was supplied. Leftover for this workaround is to find out why the number of certificate retrieved is zero in those cases, despite the fact that there's a valid 'host_certificate.pem' from tls_socket() calls. Thus still run_server_defaults() stops after 'TLS clock skew' as certificate_info() is not being called in run_server_defaults(). For now in those cases 'Problem: Host certificate found but we can't continue with "server defaults"' is being printed. In general for the future it would be great if we could e.g. retrieve the header over TLS sockets.
- Loading branch information...
Oops, something went wrong.