I'm writing a client in Java (needs to work both on the desktop JRE and on Android) for a proprietary protocol (specific to my company) carried over TLS. I'm trying to figure out the best way to write a TLS client in Java, and in particular, make sure that it does hostname validation properly. (Edit: By which, I mean checking that the hostname matches the X.509 certificate, to avoid man-in-the-middle attacks.)
JSSE is the obvious API for writing a TLS client, but I noticed from the "Most Dangerous Code in the World" paper (as well as from experimentation) that JSSE doesn't validate the hostname when one is using the SSLSocketFactory API. (Which is what I have to use, since my protocol is not HTTPS.)
So, it appears that when using JSSE, I have to do hostname validation myself. And, rather than writing that code from scratch (since I would almost certainly get it wrong), it seems that I should "borrow" some existing code that works. So, the most likely candidate I've found is to use the Apache HttpComponents library (ironic, since I'm not actually doing HTTP) and use the org.apache.http.conn.ssl.SSLSocketFactory class in place of the standard javax.net.ssl.SSLSocketFactory class.
My question is: is this a reasonable course of action? Or have I completely misunderstood things, gone off the deep end, and there's actually a much easier way to get hostname validation in JSSE, without pulling in a third-party library like HttpComponents?
I also looked at BouncyCastle, too, which has a non-JSSE API for TLS, but it appears to be even more limited, in that it doesn't even do certificate chain validation, much less hostname validation, so it seemed like a non-starter.
Edit: This question has been answered for Java 7, but I'm still curious what the "best practice" is for Java 6 and Android. (In particular, I have to support Android for my application.)
Edited again: To make my proposal of "borrow from Apache HttpComponents" more concrete, I've created a small library which contains the HostnameVerifier implementations (most notably StrictHostnameVerifier and BrowserCompatHostnameVerifier) extracted from Apache HttpComponents. (I realized all I need are the verifiers, and I don't need Apache's SSLSocketFactory as I was originally thinking.) If left to my own devices, this is the solution I will use. But firstly, is there any reason I shouldn't do it this way? (Assuming that my goal is to do my hostname validation the same way https does. I realize that itself is open to debate, and has been discussed in the thread on the cryptography list, but for now I'm sticking with HTTPS-like hostname validation, even though I'm not doing HTTPS.)
Assuming there's nothing "wrong" with my solution, my question is this: is there a "better" way to do it, while still remaining portable across Java 6, Java 7, and Android? (Where "better" means more idiomatic, already widely in use, and/or needing less external code.)
A host name verifier ensures the host name in the URL to which the client connects matches the host name in the digital certificate that the server sends back as part of the SSL connection.
You can implicitly use the X509ExtendedTrustManager
introduced in Java 7 using this (see this answer:
SSLParameters sslParams = new SSLParameters(); sslParams.setEndpointIdentificationAlgorithm("HTTPS"); sslSocket.setSSLParameters(sslParams); // also works on SSLEngine
I'm less familiar with Android, but Apache HTTP Client should be bundled with it, so it's not really an additional library. As such, you should be able to use org.apache.http.conn.ssl.StrictHostnameVerifier
. (I haven't tried this code.)
SSLSocketFactory ssf = (SSLSocketFactory) SSLSocketFactory.getDefault(); // It's important NOT to resolve the IP address first, but to use the intended name. SSLSocket socket = (SSLSocket) ssf.createSocket("my.host.name", 443); socket.startHandshake(); SSLSession session = socket.getSession(); StrictHostnameVerifier verifier = new StrictHostnameVerifier(); if (!verifier.verify(session.getPeerHost(), session)) { // throw some exception or do something similar. }
Unfortunately, the verifier needs to be implemented manually. The Oracle JRE obviously has some host name verifier implementation, but as far as I'm aware, it's not available via the public API.
There are more details about the rules in this recent answer.
Here is an implementation I've written. It could certainly do with being reviewed... Comments and feedback welcome.
public void verifyHostname(SSLSession sslSession) throws SSLPeerUnverifiedException { try { String hostname = sslSession.getPeerHost(); X509Certificate serverCertificate = (X509Certificate) sslSession .getPeerCertificates()[0]; Collection<List<?>> subjectAltNames = serverCertificate .getSubjectAlternativeNames(); if (isIpv4Address(hostname)) { /* * IP addresses are not handled as part of RFC 6125. We use the * RFC 2818 (Section 3.1) behaviour: we try to find it in an IP * address Subject Alt. Name. */ for (List<?> sanItem : subjectAltNames) { /* * Each item in the SAN collection is a 2-element list. See * <a href= * "http://docs.oracle.com/javase/7/docs/api/java/security/cert/X509Certificate.html#getSubjectAlternativeNames%28%29" * >X509Certificate.getSubjectAlternativeNames()</a>. The * first element in each list is a number indicating the * type of entry. Type 7 is for IP addresses. */ if ((sanItem.size() == 2) && ((Integer) sanItem.get(0) == 7) && (hostname.equalsIgnoreCase((String) sanItem .get(1)))) { return; } } throw new SSLPeerUnverifiedException( "No IP address in the certificate did not match the requested host name."); } else { boolean anyDnsSan = false; for (List<?> sanItem : subjectAltNames) { /* * Each item in the SAN collection is a 2-element list. See * <a href= * "http://docs.oracle.com/javase/7/docs/api/java/security/cert/X509Certificate.html#getSubjectAlternativeNames%28%29" * >X509Certificate.getSubjectAlternativeNames()</a>. The * first element in each list is a number indicating the * type of entry. Type 2 is for DNS names. */ if ((sanItem.size() == 2) && ((Integer) sanItem.get(0) == 2)) { anyDnsSan = true; if (matchHostname(hostname, (String) sanItem.get(1))) { return; } } } /* * If there were not any DNS Subject Alternative Name entries, * we fall back on the Common Name in the Subject DN. */ if (!anyDnsSan) { String commonName = getCommonName(serverCertificate); if (commonName != null && matchHostname(hostname, commonName)) { return; } } throw new SSLPeerUnverifiedException( "No host name in the certificate did not match the requested host name."); } } catch (CertificateParsingException e) { /* * It's quite likely this exception would have been thrown in the * trust manager before this point anyway. */ throw new SSLPeerUnverifiedException( "Unable to parse the remote certificate to verify its host name: " + e.getMessage()); } } public boolean isIpv4Address(String hostname) { String[] ipSections = hostname.split("\\."); if (ipSections.length != 4) { return false; } for (String ipSection : ipSections) { try { int num = Integer.parseInt(ipSection); if (num < 0 || num > 255) { return false; } } catch (NumberFormatException e) { return false; } } return true; } public boolean matchHostname(String hostname, String certificateName) { if (hostname.equalsIgnoreCase(certificateName)) { return true; } /* * Looking for wildcards, only on the left-most label. */ String[] certificateNameLabels = certificateName.split("."); String[] hostnameLabels = certificateName.split("."); if (certificateNameLabels.length != hostnameLabels.length) { return false; } /* * TODO: It could also be useful to check whether there is a minimum * number of labels in the name, to protect against CAs that would issue * wildcard certificates too loosely (e.g. *.com). */ /* * We check that whatever is not in the first label matches exactly. */ for (int i = 1; i < certificateNameLabels.length; i++) { if (!hostnameLabels[i].equalsIgnoreCase(certificateNameLabels[i])) { return false; } } /* * We allow for a wildcard in the first label. */ if ("*".equals(certificateNameLabels[0])) { // TODO match wildcard that are only part of the label. return true; } return false; } public String getCommonName(X509Certificate cert) { try { LdapName ldapName = new LdapName(cert.getSubjectX500Principal() .getName()); /* * Looking for the "most specific CN" (i.e. the last). */ String cn = null; for (Rdn rdn : ldapName.getRdns()) { if ("CN".equalsIgnoreCase(rdn.getType())) { cn = rdn.getValue().toString(); } } return cn; } catch (InvalidNameException e) { return null; } } /* BouncyCastle implementation, should work with Android. */ public String getCommonName(X509Certificate cert) { String cn = null; X500Name x500name = X500Name.getInstance(cert.getSubjectX500Principal() .getEncoded()); for (RDN rdn : x500name.getRDNs(BCStyle.CN)) { // We'll assume there's only one AVA in this RDN. cn = IETFUtils.valueToString(rdn.getFirst().getValue()); } return cn; }
There are two getCommonName
implementations: one using javax.naming.ldap
and one using BouncyCastle, depending on what's available.
The main subtleties are about:
EDIT:
To make my proposal of "borrow from Apache HttpComponents" more concrete, I've created a small library which contains the HostnameVerifier implementations (most notably StrictHostnameVerifier and BrowserCompatHostnameVerifier) extracted from Apache HttpComponents. [...] But firstly, is there any reason I shouldn't do it this way?
Yes, there are reasons not to do it this way.
Firstly, you've effectively forked a library, and you'll now have to maintain it, depending on further changes made to these classes in the original Apache HttpComponents. I'm not against creating a library (I've done so myself, and I'm not discouraging you to do so), but you have to take this into account. Are you really trying to save some space? Surely, there are tools that can remove unused code for your final product if you need to reclaim space (ProGuard comes to mind).
Secondly, even the StrictHostnameVerifier isn't compliant with RFC 2818 or RFC 6125. As far as I can tell from its code:
CN=cn.example.com
and a SAN for www.example.com
but no SAN for cn.example.com
be valid for cn.example.com
when it shouldn't.It's hard to see a general "better way". Giving this feedback to the Apache HttpComponents library would be one way of course. Copying and pasting the code I wrote earlier above certainly doesn't sound like a good way either (snippets of code on SO generally aren't maintained, are not 100% tested and may be prone to errors).
A better way might be to try to try to convince the Android development team to support the same SSLParameters
and X509ExtendedTrustManager
as it was done for Java 7. This still leaves the issue of legacy devices.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With