TLS с SNI в клиентах Java - PullRequest
Новая
       17

TLS с SNI в клиентах Java

8 голосов
/ 10 мая 2010

В рабочей группе NHIN Direct постоянно обсуждается проблема безопасности и доверия , связанная с проблемой сопоставления IP-адресов с доменом, созданной с использованием традиционного SSL .Если HISP (согласно определению NHIN Direct) хочет разместить у себя тысячи «доменов работоспособности» NHIN Direct для провайдеров, то это будет «искусственно завышенная стоимость» для покупки IP для каждого из этих доменов.

Поскольку Apache и OpenSSL недавно выпустили TLS с поддержкой расширения SNI, можно использовать SNI в качестве решения этой проблемы на стороне сервера .Однако, если мы решим, что разрешим реализации сервера транспортного уровня NHINDirect для поддержки TLS + SNI, то мы должны потребовать , чтобы все клиенты также поддерживали SNI.Клиенты, основанные на OpenSSL, должны делать это по умолчанию, и мы всегда можем использовать клиент с поддержкой TLS + SNI для прокси, если ваша реализация SSL на языке программирования не поддерживает SNI.Похоже, что нативные Java-приложения, использующие OpenJDK, еще не поддерживают SNI, но я не могу получить прямой ответ из этого проекта.Я знаю, что есть доступные библиотеки Java OpenSSL, но я понятия не имею, можно ли считать это жизнеспособным.

Можете ли вы дать мне сводку «по последнему слову техники» о поддержке TLS + SNI для клиентов Java?Мне нужна перспектива реализации Java на этом.

Ответы [ 3 ]

8 голосов
/ 05 января 2012

JavaSE 7 имеет поддержку SNI в JSSE.

http://docs.oracle.com/javase/7/docs/technotes/guides/security/enhancements-7.html

Обратите внимание, что, похоже, проблема в этом, как вы можете прочитать здесь:

Предупреждение о рукопожатии SSL: ошибка неопознанного имени после обновления до Java 1.7.0

6 голосов
/ 27 декабря 2012

также можно добавить несколько строк в начало JDK Sun (bootclasspath), чтобы заставить работать SNI сервера.

Класс: sun.security.ssl.ServerHandshaker

Добавить поле 

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

Patch Method clientHello (добавьте эти строки) 

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

Patch Method setupPrivateKeyAndChain (изменить) 

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

Добавить в класс sun.security.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()]);
}
3 голосов
/ 10 мая 2010

Я работаю над тем же проектом, что и ftrotter.

Обратите внимание на требование поддержки тысяч доменов. Я не думаю, что SAN собираются сократить горчицу по двум причинам. Во-первых, размер сертификата станет огромным, что, скорее всего, приведет к проблемам с производительностью как минимум. Во-вторых, эти домены будут приходить и уходить часто, особенно в первые дни NHIN Direct. Оперативное бремя обновления сертификата каждый раз, когда домен приходит или уходит, будет неприемлемым, ИМХО.

По запросу ftrotter я немного погуглил на предмет java, TLS и SNI и других способов реализации того, что равнозначно ситуации с виртуальным хостингом на основе имен, с одним сертификатом на виртуальный хост. Вот что я придумала:

  • JSSE (Java Secure Socket Extension) поддерживает TLS и имеет «частичную поддержку» для TLS + SNI. Я понятия не имею, что означает частичная поддержка в этом контексте. Комментарий, который я вижу, указывает на то, что существующая поддержка не подходит для создания виртуальных хостов на основе имен, что, в основном, нам и нужно.

  • Я нашел одну статью, в которой утверждается, что версия JSSE для JDK7 будет поддерживать TLS + SNI (от 20.11.2008), и я нашел одну, которая утверждает, что она выиграла ' т (от 27.02.2009). Ни один из них не является особенно авторитетным.

  • Некоторые ребята, работающие над OpenJDK 7, обсуждали вопросы, связанные с добавлением поддержки SNI в JSSE еще в феврале-марте 2009 года, включая публикацию исходного патча. (поток начинается здесь: http://www.mail-archive.com/security-dev@openjdk.java.net/msg00612.html). OpenJDK7 не будет выпущен до сентября 2010 года. Я понятия не имею, когда выйдет платформа Java 7.

  • На java.sun.com нет ничего существенного, так что я действительно не знаю, какие планы у Sun вообще.

  • Существует, очевидно, другой способ создания виртуальных хостов на основе имен, который, по-видимому, широко совместим, используя один сертификат для каждого хост-сервера, который содержит несколько общих имен и несколько альтернативных имен субъектов. См. http://wiki.cacert.org/VhostTaskForce и Предоставлять разные сертификаты для одного и того же приложения Tomcat через разъемы?

Этот подход будет создавать действительно большие сертификаты (из-за всех этих CN и SAN), если у вас много виртуальных хостов. Один из участников недавней личной встречи NHIN Direct говорил о желании поддержать тысяч виртуальных хостов. Я предполагаю, что это сломает много реализаций. Кроме того, необходимость обновлять сертификат каждый раз, когда вы добавляете или удаляете виртуальный хост, звучит как нелепая операционная нагрузка.

Таким образом, текущее состояние Java для виртуального хостинга на основе имен с отдельными сертификатами для каждого виртуального хоста, похоже, "не может делать". Кроме того, неясно, когда или если он будет добавлен.

Кто-нибудь соглашается или не соглашается? Кто-нибудь знает, есть ли у проекта OpenJDK какие-либо намерения «перенести» поддержку SNI для Java 6?

...