Java SSL DH Keypair Generation - Prime Size Error

Question

Я в настоящее время внедряю Reddit OAuth2 для входа в мое веб-приложение. Рукопожатие и маркер обмен работает нормально при проверке на месте, но при запуске на сервере (размещено на DIY картриджа «OpenShift») я получаю следующее сообщение об ошибке:

java.security.InvalidAlgorithmParameterException: Prime size must be 
multiple of 64, and can only range from 512 to 1024 (inclusive) 

Что приводит

java.lang.RuntimeException: Could not generate DH keypair 

I мы искали большую часть дня и находили различные решения, начиная от изменения версии Java и заканчивая использованием BouncyCastle. Тем не менее, я использую библиотеку Scribe, поэтому я не думаю, что могу реализовать BouncyCastle без наложения и изменения базы писца, какой вид поражения это цель.

Установка JCE Unlimited Strength также появилась, но я не могу этого сделать на OpenShift, так как нет доступа root (возможно, она сможет заставить одну из их команды сделать это).

В версии Java в пользе (взяты из java -version):

локального тестирования машины:

java version "1.7.0_51" 
OpenJDK Runtime Environment (IcedTea 2.4.4) (7u51-2.4.4-1ubuntu1) 
OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode) 

OpenShift Сервер:

java version "1.7.0_51" 
OpenJDK Runtime Environment (rhel-2.4.4.1.el6_5-i386 u51-b02) 
OpenJDK Server VM (build 24.45-b08, mixed mode) 

Я в недоумении относительно того, что Я могу это сделать. Надеюсь, я глуп или что-то не понимаю, поэтому любые возможные решения были бы замечательными!

-

EDIT 1

Запрос код, который возвращает ошибку (используя Scribe, как я уже говорил, так что не может быть много пользы). Конечная точка маркера равна https://ssl.reddit.com/api/v1/access_token с использованием POST. Как я сказал выше, это работает на моей тестовой машине.

OAuthRequest request = new OAuthRequest(getAccessTokenVerb(), getAccessTokenEndpoint()); 

request.addHeader("Authorization", "Basic" 
    +Base64.encode((config.getApiKey()+":"+config.getApiSecret()).getBytes())); 

request.addBodyParameter("state", "none"); 
request.addBodyParameter(OAuthConstants.SCOPE, config.getScope()); 
request.addBodyParameter(OAuthConstants.CLIENT_ID, config.getApiKey()); 
request.addBodyParameter(OAuthConstants.REDIRECT_URI, config.getCallback()); 
request.addBodyParameter(OAuthConstants.CODE, verifier.getValue()); 
request.addBodyParameter("grant_type", "authorization_code"); 

Response response = request.send(); // Errors here from Request.createConnection in the Scribe code 
return getAccessTokenExtractor().extract(response.getBody()); 

Answer 1

Во-первых, «Безлимитный сила» здесь неуместна. Это исправит совершенно другую проблему, из-за которой вы не можете использовать шифровые наборы с использованием AES-256 (и если сторонник настаивает на них, это не может быть рукопожатием вообще). Кроме того, битрейт JVM не имеет значения; это (не совсем обоснованное) ограничение на DH находится в байт-коде «run-везде» в SunJCE.

Вы можете использовать BouncyCastle в качестве поставщика криптозащиты, не меняя код, который выполняет SSL-соединения (в вашем случае Scribe), но из того, что я прочитал, создавая BC, предпочтительный поставщик вызывает другие проблемы. Если вы все равно хотите попробовать, поместите bcprov-version.jar в JRE/lib/exit и отредактируйте JRE/lib/security/java.security; или поместите его куда-нибудь в свой путь к классу и получите код инициализации java.security.Security.insertProviderAt (новый org.bouncycastle.jce.provider.BouncyCastleProvider(), позиция);

Предлагаю начать с того, почему ваша местная система работает. Когда я пытаюсь ssl.reddit.com с openssl, он поддерживает как ECDHE-RSA (с P-256), так и DHE-RSA с dh 2048 бит. Suncle Java 7 поддерживает и предпочитает ECDHE, и я ожидал бы, что OpenJDK также будет работать, но, возможно, нет, а может быть, и нет; Я знаю, что RedHat до недавнего времени опустил ECC в своих rpms of openssl, и это не удивило бы меня, если бы они это сделали и в openjdk. Если вы скомпилируете и запустите следующую команду (с помощью ssl.reddit.com 443), она сообщит, какой пакет согласован в вашей системе, используя все настройки SSL по умолчанию для вашей JRE (что я ожидаю и надеюсь, что Scribe также использует):

//nopackage DThompson 2012.08.13b 
import java.net.InetSocketAddress; 
import java.net.Socket; 
import javax.net.ssl.SSLSocket; 
import javax.net.ssl.SSLSocketFactory; 

public class JustBConnectSSL { 

    /* (optionally bind and) just make SSL connection, for testing reach and trust 
    * uses default providers, truststore (normally JRE/lib/security/[jsse]cacerts), 
    * and keystore (normally none), override with -Djavax.net.ssl.{trust,key}Store* 
    */ 
    public static void main (String[] args) throws Exception { 
     if(args.length < 2){ System.out.println ("Usage: tohost port [fromaddr [fromport]]"); return; } 
     Socket sock = SSLSocketFactory.getDefault().createSocket(); 
     if(args.length > 2) 
      sock.bind (new InetSocketAddress (args[2], args.length>3? Integer.parseInt(args[3]): 0)); 
     sock.connect (new InetSocketAddress (args[0], Integer.parseInt(args[1]))); 
     System.out.println (sock.getInetAddress().getHostName() + " = " + sock.getInetAddress().getHostAddress()); 
     ((SSLSocket)sock).startHandshake(); 
     System.out.println ("connect okay " + ((SSLSocket)sock).getSession().getCipherSuite()); 
    } 
} 

Если тест получает _DHE_RSA_something, поставщики криптографии в вашей JRE должны отличаться от Suncle, либо измененными Ubuntu, либо некоторой настройкой или патчем в вашей системе. Если тест получает _ECDHE_RSA_something, но OpenShift этого не делает, они могут как-то отключить ECC/ECDHE. Если они позволят это лучше всего (ECDHE-P-256 по крайней мере безопасен и, вероятно, более эффективен, чем DH-2048). В противном случае, пока Oracle не исправляет это (видимо, в 8), единственный, на что я полагаю, можно полагаться, это отключить DHE-пакеты (и вернуться к простому RSA, что может быть небезопасно для NSA); это самый простой код, который фактически создает SSLSocket, но если Scribe (например, большинство веб-клиентов java) использует URL -> HttpsUrlConnection со своим SSLSocketFactory по умолчанию, вы можете заменить модифицированный завод, который изменяет список EnabledCiphers по строкам вопроса # 6851461 (хотя для хоста с хорошим общедоступным сертификатом вам не нужны части пользовательского доверия для этого решения).

Answer 2

Не уверен, если это имеет значение, но версия OpenJDK работает на OpenShift составляет 32 бит, вы можете просматривать это с помощью System.getProperty («sun.arch.data.model») в вашем коде.

Я написал быстрый класс только выходной бит-Несс и скомпилирован на передаче OpenShift и запустил его и получил 32

class Test { 

public static void main(String[] args) { 

System.out.println(System.getProperty("sun.arch.data.model")); 

} 

} 

Answer 3

Я знаю, что очень поздно ответить на это, но я боролся с подобной проблемой, а затем решил ее. Мое решение для MAC-OS.

1. Установите Надувной замок баночку из http://www.bouncycastle.org/latest_releases.html, в /Library/Java/JavaVirtualMachines // Содержание/Начало/JRE/Библиотека/внутр
2. редактировать java.security файл добавить следующую строку security.provider. 2 = org.bouncycastle.jce.provider.BouncyCastleProvider , а затем переупорядочить всех других поставщиков, которые у вас могут быть.
3. вуаля

Answer 4

Я решил проблему на оракула Java 8, переключаясь на BouncyCastle поставщика для SSL/TLS:

1. Добавлена ​​BouncyCastle к моему проекту

   <dependency> 
       <groupId>org.bouncycastle</groupId> 
       <artifactId>bcprov-jdk15on</artifactId> 
       <version>1.54</version> 
   </dependency> 
   

2. Перед тем, как делать какие-либо материалы SSL, я добавляю поставщика BouncyCastle в качестве первого провайдера в список:

   Security.insertProviderAt(new BouncyCastleProvider(),1); 
   

Это все. Теперь мои подключения к сайтам с 4096-разрядными параметрами DH работают как ожидалось (я использую Apache HTTP Client). Это также должно работать с jdk 7.