Does not do any TLS hostname verification by default

[frewsxcv]

Currently, hyper does not provide any hostname verification when working with TLS. Ideally, Hyper would use a library similar to https://github.com/pyca/service_identity to prevent MITM attacks from happening.

[seanmonstar]

The issue here is that hyper needs to pick something by default.

It's already possible to do it yourself with Client.set_ssl_verifier().

[tarcieri]

For what it's worth, I just implemented RFC 6125-compliant hostname verification for Ruby's OpenSSL extension (a.k.a. CVE-2015-1855):

https://github.com/ruby/openssl/pull/12/files

I'd be happy to do a Rust implementation.

[frewsxcv]

Worth noting this is also an issue in Servo: servo/servo#4954

[tarcieri]

I just started an RFC6125 hostname verification library for Rust:

https://github.com/tarcieri/pkixnames

[tarcieri]

One thing I'm curious about... what type is used for representing presented identifiers? I think I'd like the internal implementation of this library to be done completely as Vec<u8>s

[veeti]

Hyper doesn't seem to do any TLS verification right now with the default client settings. Any untrusted certificate goes.

[seanmonstar]

@tarcieri I don't know what presented identifiers means in this context.

[tarcieri]

@seanmonstar the subjectAlternativeNames (SANs) or Common Names (CNs) in X.509 certificates

[seanmonstar]

Ah, I have no idea. That would be in the openssl lib, no?

On Sun, Apr 26, 2015, 2:21 PM Tony Arcieri notifications@github.com wrote:

@seanmonstar https://github.com/seanmonstar the subjectAlternativeNames
(SANs) or Common Names (CNs) in certificates

—
Reply to this email directly or view it on GitHub
#472 (comment).

[tarcieri]

It's beginning to seem like rust-openssl is probably where I should be asking about this 😉