TLS avec SNI en Java clients

Je suis en train de travailler sur le même projet que ftrotter.

Remarque: l'exigence de soutien pour milliers de domaines. Je ne pense pas que SANs allons couper la moutarde pour deux raisons. Tout d'abord, la taille du certificat va devenir énorme, qui risquent d'entraîner des problèmes de performances à un minimum. Deuxièmement, ces domaines vont et viennent fréquemment, en particulier dans les premiers jours de NHIN Direct. Le fardeau opérationnel de devoir mettre à jour le certificat à chaque fois un domaine vient ou va, va être inacceptable, à mon humble avis.

À ftrotter demande, j'ai fait quelques recherches sur google sur le sujet de java, TLS et de la SNI, et d'autres façons de mettre en œuvre ce qui équivaut à un nommé hébergement virtuel basé sur la situation, avec un certificat par l'hôte virtuel. Voici ce que j'ai trouvé:

• JSSE (Java Secure Socket Extension) prend en charge TLS, et a "une prise en charge partielle" pour TLS+SNI. Je n'ai aucune idée de ce qu'une prise en charge partielle signifie dans ce contexte. Le commentaire, je suis voyant indique que le soutien qui existe n'est pas suffisant pour faire nommée hôtes virtuels basés sur l', qui est essentiellement ce que nous avons besoin.

• J'ai trouvé un article qui prétend le JDK7 version de JSSE sera prise en charge de TLS+SNI (daté 11/20/2008), et j'en ai trouvé un qui prétend qu'il ne va pas (daté 2/27/2009). Ni est particulièrement autoritaire.

• Certains des gens qui travaillent sur OpenJDK 7 discuté les questions autour de l'ajout de SNI soutien à JSSE de retour en Février-mars 2009, incluant l'affichage d'une source de patch. (thread commence ici:
  http://www.mail-archive.com/[email protected]/msg00612.html). OpenJDK7 ne va pas être libérés quelque temps avant septembre 2010. Je n'ai aucune idée de quand la Java 7 plate-forme sera libéré.

• Il n'y a rien de fond sur java.sun.com à tous, donc je ne sais vraiment pas ce que Sun plans sont à tous les.

• Apparemment, il y a une façon différente de faire des serveurs virtuels par nom qui est apparemment largement compatible, à l'aide d'un seul certificat par le serveur qui l'héberge qui contient plusieurs noms communs et plusieurs autres noms. Voir http://wiki.cacert.org/VhostTaskForce et Servir les différents certificats pour la même application Tomcat à l'aide des connecteurs?

Cette approche permettrait de créer de très grandes certificats (à cause de tous ceux Snc et SANs) si vous avez beaucoup de serveurs virtuels. L'un des gens de chez NHIN Direct récente de face-à-face a été de parler au sujet de vouloir soutenir milliers des hôtes virtuels. Ma conjecture est que cela va casser beaucoup de mises en œuvre. En outre, le fait de mettre à jour le certificat à chaque fois que vous ajoutez ou supprimez un hôte virtuel sonne comme un ridicule charge opérationnelle.

En résumé, l'actuel Java état de l'art pour l'hébergement virtuel par nom avec certificats séparés par hôte virtuel semble être "non". En outre, il n'est pas clair quand ou si elle sera ajoutée.

Quelqu'un d'accord ou pas d'accord? Personne ne sait si le projet OpenJDK a aucune intention de "le portage" SNI prise en charge de Java 6?

OriginalL'auteur user337533

il est également possible de le patcher avec quelques lignes de l'orig Sun JDK (bootclasspath) pour obtenir Serveur SNI de travail.

Classe: le soleil.de sécurité.le protocole ssl.ServerHandshaker

Ajouter Un Champ

    /** Use for SNI */
    private ServerNameExtension serverNameExtension = null;

Patch Méthode clientHello (ajouter ces lignes)

    /* Use for SNI */
    this.serverNameExtension = (ServerNameExtension)mesg.extensions.get(ExtensionType.EXT_SERVER_NAME);

Patch Méthode setupPrivateKeyAndChain (changer)

    if (this.conn != null) { alias = km.chooseServerAlias(algorithm      , null, this.conn);
    } else                 { alias = km.chooseEngineServerAlias(algorithm, null, this.engine); }

to

    final Principal[] principals = (this.serverNameExtension == null) ? null : this.serverNameExtension.getHostnamePrincipals();
    if (this.conn != null) { alias = km.chooseServerAlias(algorithm      , principals, this.conn);
    } else                 { alias = km.chooseEngineServerAlias(algorithm, principals, this.engine); }

Ajouter à la Classe soleil.de sécurité.le protocole ssl.ServerNameExtension

static final class ServerNamePrincipal implements Principal {
    private final String name;
    ServerNamePrincipal(final String name) { this.name = name; }
    @Override public String getName() { return this.name; }
    @Override public String toString() { return this.name; }
}

public Principal[] getHostnamePrincipals() {
    final List<Principal> principals = new LinkedList<>();
    for(final ServerName name : this.names) {
        if(name.type == NAME_HOST_NAME) { principals.add(new ServerNamePrincipal(name.hostname)); }
    }
    return principals.toArray(new Principal[principals.size()]);
}

OriginalL'auteur SkateScout