pyopenssl
pyopenssl copied to clipboard
pyca
Add support for server hostname verification
In the past I believe people have used service_identity.pyopenssl.verify_hostname to handle this case, but now that OpenSSL properly includes a way to validate it makes sense to potentially expose it here. Unfortunately, X509_VERIFY_PARAM_set1_host is a 1.0.2+ feature and we still support 1.0.1 so we'll have to either have a fallback through service_identity or raise an exception if this is called when cryptography is compiled against 1.0.1.
@hynek this touches a thing you actually care about, opinions?
Ah thanks for the reminder Christian. I'll put that note over on the cryptography PR as well, sigh.
If LibreSSL was the only think that didn't support this, I'd drop it in a heartbeat.
On Tue, Oct 9, 2018 at 9:53 PM Christian Heimes [email protected] wrote:
@reaperhulk https://github.com/reaperhulk You also need the fallback for LibreSSL < 2.7.1.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/pyca/pyopenssl/pull/796#issuecomment-428410845, or mute the thread https://github.com/notifications/unsubscribe-auth/AAADBHona7phzAefWrj6gA9Cmr6ttJDYks5ujVL9gaJpZM4XUJDf .
-- All that is necessary for evil to succeed is for good people to do nothing.
Obviously, supporting native APIs is the right thing to do. Pls Sherlock service_identity. ;)
Obviously, supporting native APIs is the right thing to do. Pls Sherlock service_identity. ;)
Can you please explain what you mean with "Sherlock service_identity"?
Unfortunately,
X509_VERIFY_PARAM_set1_hostis a 1.0.2+ feature and we still support 1.0.1 so we'll have to either have a fallback through service_identity or raise an exception if this is called whencryptographyis compiled against 1.0.1.
I've submitted code that raises an exception.
Now that the base changes have been added to cryptography, this might be ready for review again.
Is the approach using the exception sufficient for initial support? Do you require me to implement a fallback to service_identity?
No, I think an exception and leaving it up to consumers is fine.
What do you think about using the IGNORE_SUBJECT flag, if it's available? That's what browsers are doing these days, and it resolves various potential issues stemming from the CommonName being untyped.
What do you think about using the IGNORE_SUBJECT flag, if it's available? That's what browsers are doing these days, and it resolves various potential issues stemming from the CommonName being untyped.
Is "fallback to CN" allowed if the SAN extension is absent? Is the requirement "SAN must be present" something specific to the "CA Baseline Requirements" that browser vendors are enforcing as part of the CABForum work? If it's specific to the browser world, but CN is still allowed as a fallback for non-browser sites, maybe forbidding the fallback in general might be too strict? Maybe we should allow some parameterizing of the new function?
RFC 6125 encourages moving away from CN, so it's not just the CABF.
Since this is a new API, I'd like to see if we can be aggressive about encouraging modern practices.
OK, sounds good. Because python offers default parameters, there will be the option to introduce an optional additional parameter at a later time, if necessary.
Regarding the function name, in order to be consistent with the existing set_tlsext_host_name, maybe the new name should be set_verify_host_name.
Please take a look at the failing builds here -- you can ignore the 1.1.0 build which has some unrelated fallout from 1.1.1.
Thanks for the explanation. I've fixed the whitespace and style issues. It's mostly green now. Two travis configurations appear to experience infrastructure/connectivity issues.
Yeah, I'm restarting those builds. Which is annoying, but not an issue for you.
We'll try to get you a proper review of the substance soonish.