Comment dois-je faire validation de nom de domaine lors de l'utilisation de JSSE?

Java 7 (et ci-dessus)

Vous pouvez implicitement utiliser le X509ExtendedTrustManager introduit dans Java 7 à l'aide de ce (voir cette réponse:

SSLParameters sslParams = new SSLParameters();
sslParams.setEndpointIdentificationAlgorithm("HTTPS");
sslSocket.setSSLParameters(sslParams); //also works on SSLEngine

Android

Je suis moins familier avec Android, mais Apache HTTP Client devrait être fourni avec, donc il n'est pas vraiment une bibliothèque supplémentaire. En tant que tel, vous devriez être en mesure d'utiliser org.apache.http.conn.ssl.StrictHostnameVerifier. (Je n'ai pas essayé ce 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.
}

Autres

Malheureusement, le vérificateur doit être mis en œuvre manuellement. L'Oracle JRE a évidemment certains nom d'hôte vérificateur de mise en œuvre, mais autant que je sache, il n'est pas disponible via l'API publique.

Il y a plus de détails sur les règles de cette récente réponse.

Voici une application que j'ai écrit. Il pourrait certainement être revu... des Commentaires et de la rétroaction de bienvenue.

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;
}

Il y a deux getCommonName implémentations: à l'aide d' javax.naming.ldap et une à l'aide de BouncyCastle, selon ce qui est disponible.

Les principales subtilités sont sur:

• Adresse IP correspondante seulement dans SANs (Cette question est à propos de l'adresse IP de correspondance et d'autres Noms de l'Objet.). Peut-être quelque chose pourrait être fait à propos de l'IPv6 correspondant trop.
• Des jokers.
• Seulement pour retomber sur la CN si il n'y a pas de DNS SAN.
• Ce que le "plus spécifiques" CN signifie vraiment. J'ai supposé que c'est le dernier ici. (Je suis même pas envisagé une seule CN RDN avec plusieurs Attribut-Valeur des Assertions (AVA): BouncyCastle pouvez traiter avec eux, mais c'est un cas extrêmement rares de toute façon, autant que je sache.)
• Je n'ai pas vérifié à tout ce qui doit arriver pour internationalisées (non ASCII) noms de domaine (voir RFC 6125.)

MODIFIER:

Pour faire ma proposition de "emprunter de Apache HttpComponents" plus
le béton, j'ai créé une petite bibliothèque, qui contient la
HostnameVerifier implémentations (notamment StrictHostnameVerifier
et BrowserCompatHostnameVerifier) extrait de Apache
HttpComponents. [...] Mais tout d'abord, est-il une raison que je ne devrais pas le faire
de cette façon?

Oui, il y a des raisons de ne pas le faire de cette façon.

Tout d'abord, vous avez effectivement fourchue, une bibliothèque, et vous aurez maintenant à maintenir, selon d'autres modifications apportées à ces classes à l'origine, Apache HttpComponents. Je ne suis pas contre la création d'une bibliothèque (je l'ai fait moi-même, et je ne suis pas vous décourager, vous de le faire), mais vous devez prendre cela en compte. Êtes-vous vraiment essayer de gagner de l'espace? Certes, il existe des outils qui peuvent supprimer les code final de votre produit si vous avez besoin de récupérer de l'espace (ProGuard vient à l'esprit).

D'autre part, même les StrictHostnameVerifier n'est pas conforme aux RFC 2818 ou RFC 6125. Aussi loin que je peux dire à partir de son code:

• Il accepte les adresses IP dans la CN, quand il ne devrait pas.
• Il ne sera pas seulement tomber en arrière sur le CN lorsque aucun DNS SANs sont présents, mais aussi de traiter le CN comme un premier choix trop. Cela pourrait conduire à une cert avec CN=cn.example.com et un saint pour www.example.com mais pas SAN pour cn.example.com être valable pour cn.example.com quand il ne devrait pas.
• Je suis un peu sceptique sur la façon dont le CN est extrait. Sujet DN chaîne de la sérialisation peut être un peu drôle, surtout si certains RDNs inclure des virgules, et le maladroit cas où certains RDNs peut avoir plusieurs AVAs.

C'est dur de voir un général "meilleure façon". En donnant cette rétroaction de l'Apache HttpComponents bibliothèque serait un moyen de cours. De copier et de coller le code que j'ai écrit plus tôt ci-dessus n'est certainement pas une bonne manière ou d'une autre (extraits de code, DONC, ne sont généralement pas conservés, ne sont pas 100% testés et peuvent être sujettes à des erreurs).

Une meilleure façon peut-être pour tenter de convaincre l'équipe de développement Android à l'appui de la même SSLParameters et X509ExtendedTrustManager comme cela a été fait pour Java 7. Cela laisse tout de même la question de l'héritage des appareils.