Wie sollte ich das tun hostname-Validierung bei der Verwendung von JSSE?

Java 7 (und höher)

Können Sie verwenden implizit die X509ExtendedTrustManager eingeführt in Java 7 mit diesem (siehe diese Antwort:

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

Android

Ich bin weniger vertraut mit Android, aber der Apache HTTP-Client sollte gebündelt werden, so dass es nicht wirklich eine zusätzliche Bibliothek. Als solche, sollten Sie in der Lage sein zu verwenden org.apache.http.conn.ssl.StrictHostnameVerifier. (Ich habe nicht versucht mit diesem 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.
}

Anderen

Leider, der Prüfstelle umgesetzt werden muss manuell. Die Oracle JRE hat offensichtlich einige host-name verifier Umsetzung, aber soweit ich weiß, ist es nicht verfügbar, über die öffentliche API.

Gibt es mehr details über die Regeln in diese neue Antwort.

Hier ist eine Implementierung, die ich geschrieben habe. Es könnte durchaus mit überprüft... die Kommentare und Rückmeldungen sind willkommen.

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

Gibt es zwei getCommonName Implementierungen: eine über javax.naming.ldap und eins, BouncyCastle, je nachdem, was verfügbar ist.

Den wichtigsten Feinheiten sind etwa:

• Passende IP-Adresse nur in SANs (Diese Frage ist über die IP-Adresse passenden und Subject Alternative Names.). Vielleicht könnte etwas getan werden um IPv6-matching zu.
• Wildcard-matching.
• Nur fallen zurück auf die CN, wenn keine DNS-SAN.
• Was die "spezifischsten" CN wirklich bedeutet. Ich bin davon ausgegangen das ist die Letzte hier. (Ich bin nicht einmal in Erwägung ziehen eine einzelne RDN CN mit mehreren Attribut-Wert-Behauptungen (AVA): BouncyCastle mit Ihnen umgehen, aber dies ist eine extrem seltene Fall jedenfalls soweit ich weiß.)
• Ich habe nicht überprüft, was passieren soll, für internationalisierte (nicht-ASCII) domain-Namen (siehe RFC 6125.)

BEARBEITEN:

Meinen Vorschlag "ausleihen von Apache HttpComponents" mehr
konkret, ich habe eine kleine Bibliothek enthält dem
HostnameVerifier-Implementierungen (vor allem StrictHostnameVerifier
und BrowserCompatHostnameVerifier) extrahiert aus Apache
HttpComponents. [...] Aber Erstens, gibt es einen Grund, ich sollte das nicht tun
es auf diese Weise?

Ja, es gibt Gründe, es nicht zu tun auf diese Weise.

Erstens, Sie haben effektiv Gabel eine Bibliothek, und nun müssen Sie pflegen, je nach weiteren änderungen an diesen Klassen, die in der original-Apache HttpComponents. Ich bin nicht gegen die Schaffung einer Bibliothek (ich habe es selbst getan, und ich bin nicht entmutigt Sie, dies zu tun), aber Sie müssen dies berücksichtigen. Sind Sie wirklich versucht, etwas Platz zu sparen? Sicher, es gibt tools, entfernen Sie unbenutzte code für Ihr Finales Produkt, wenn Sie brauchen, um Platz frei zu machen (ProGuard in den Sinn kommt).

Zweitens, auch die StrictHostnameVerifier ist nicht kompatibel mit RFC 2818 oder RFC 6125. So weit wie ich kann sagen, aus seiner code:

• Akzeptiert er die IP-Adressen der CN, wenn es nicht sollte.
• Es wird nicht nur fallen zurück auf die CN, wenn keine DNS-SANs vorhanden sind, sondern behandeln auch die CN als erste Wahl zu. Dies könnte dazu führen, ein cert mit CN=cn.example.com und eine SAN für www.example.com aber keine SAN für cn.example.com gültig für cn.example.com wenn es nicht sollte.
• Ich bin ein bisschen skeptisch über die Art und Weise der CN extrahiert wird. Subject DN-string serialisieren kann ein bisschen komisch, vor allem, wenn einige RDNs Kommas, und der peinliche Fall, in dem einige RDNs kann mehrere AVAs.

Es ist schwer zu sehen, ein Allgemeines "besser Weg". Geben Sie diese Rückmeldung an die Apache HttpComponents-Bibliothek wäre eine Möglichkeit natürlich. Kopieren und einfügen der code, den ich schrieb oben sicherlich nicht klingen wie eine gute Möglichkeit, entweder (code-Schnipsel auf, ALSO in der Regel nicht gepflegt, sind nicht zu 100% getestet und kann anfällig für Fehler).

Bessere Weg sein könnte, um zu versuchen, um zu versuchen zu überzeugen, die Android development team unterstützen die gleichen SSLParameters und X509ExtendedTrustManager als es fertig war für Java 7. Dies lässt immer noch die Frage der legacy-Geräte.