4 ms·
Looks like they weren't checking the hostname in the certificate. This would allow anyone with a certificate signed by a trusted CA to do a MITM attack on iOS d
by nekitamo 13y ago
Looks like they weren't checking the hostname in the certificate. This would allow anyone with a certificate signed by a trusted CA to do a MITM attack on iOS devices. Very very bad vulnerability.
- mikeash 13y agoIt seems to be a bit more than that, as I've verified that iOS 7.0.4 and Mac OS X 10.9.1 both refuse to connect to a server with a certificate for a different hostname. Sounds like verification is somehow different when connecting to a raw IP address. Safari treats that case differently, anyway: if I try to connect to a hostname that's different from what the certificate says, it simply refuses to establish the connection at all. If I try to connect to the raw IP address, it says the certificate is wrong, but gives me the choice to ignore the error and proceed anyway. Odd stuff.
- MichaelGG 13y agoMaybe due to lots of appliances that run HTTPS with a self-signed cert to "productname", but are often accessed via an IP?
- makomk 13y agoLooking at the code, this bug probably doesn't happen on connections which use TLS 1.2, which any properly configured server should support these days. (There's a seperate codepath for TLS 1.2 connections.) Note that this doesn't provide any protection against an attacker exploiting the vulnerability, since they get to choose what TLS version is used.