OpenSSL: wyświetlanie parametrów DH

15

Podczas korzystania z szyfrów SSL polegających na różnej wymianie klucza hellmana, wielkość zastosowanego klucza prywatnego ma kluczowe znaczenie dla bezpieczeństwa tej wymiany kluczy.

Kiedy mogę połączyć się z serwerem za pomocą narzędzia „openssl s_client”, w jaki sposób mogę zapytać o zastosowane parametry DH?

openssl
źródło

Odpowiedzi:

17

Nie znam łatwego w użyciu przełącznika wiersza polecenia, ale w openssl s_clientwierszu polecenia możesz dodać -msgopcję uzyskania szesnastkowego zrzutu wiadomości uścisku dłoni. Następnie poszukaj ServerKeyExchangewiadomości; To powinno wyglądać tak:

<<< TLS 1.2 Handshake [length 030f], ServerKeyExchange
    0c 00 03 0b 01 00 ff ff ff ff ff ff ff ff c9 0f
    da a2 21 68 c2 34 c4 c6 62 8b 80 dc 1c d1 29 02
    4e 08 8a 67 cc 74 02 0b be a6 3b 13 9b 22 51 4a
    (...)

i brzmi w ten sposób:

  • 0c 00 03 0b: komunikat typu „ServerKeyExchange” (to jest „0c”) o długości 0x00030B bajtów.
  • Pierwszym elementem jest moduł DH jako duża liczba całkowita z nagłówkiem o długości dwóch bajtów. Tutaj długość jest zakodowana jako 01 00, co oznacza liczbę całkowitą zakodowaną na 0x0100 bajtów. To 256 bajtów, więc moduł ma długość od 2041 do 2048 bitów.
  • Następują moduły bajtów, w niepodpisanej kolejności big-endian. Górne bajty tego modułu to w tym przypadku ff ff ff ff.... Moduł ma wtedy długość dokładnie 2048 bitów.

Jeśli korzystasz z zestawu szyfrów ECDHE (krzywa eliptyczna), wówczas ServerKeyExchangeformat jest oczywiście inny.

Zobacz standard definicji ServerKeyExchangewiadomości. W przypadku zestawów szyfrów DHE zawiera moduł p , generator g i klucz publiczny y serwera DH , w tej kolejności, każdy wyrażony jako duża liczba całkowita w formacie opisanym powyżej (16-bitowy nagłówek zawierający długość w bajtach, a następnie liczba całkowita wartość w niepodpisanym kodowaniu big-endian).

Nowsze wersje biblioteki mają tendencję, aby wybrać rozmiar DH Moduł, który w meczach (z punktu widzenia bezpieczeństwa) siłą pary kluczy serwera (używany do podpisania do ServerKeyExchangewiadomości). W powyższym przykładzie serwer ma 2048-bitowy klucz RSA, więc OpenSSL zdecydował się na użycie 2048-bitowego modułu DH (w tym przypadku dobrze znany moduł opisany w RFC 3526, sekcja 3 ).

Niektóre inne serwery trzymają się 1024-bitowych grup DH w celu zapewnienia zgodności z niektórymi istniejącymi klientami, które nie obsługują większych grup DH (największym przestępcą jest implementacja SSL w Javie, naprawiona w Javie 8 kompilacja 56 w 2012 r.). Znaną wadą protokołu TLS dla zestawów szyfrów DHE jest to, że klient nie ma możliwości określenia, jaki rozmiar modułu może obsługiwać (jest to naprawione w ECDHE, ponieważ klient może określić dokładną listę krzywych, które akceptuje) .

Thomas Pornin
źródło
1
OpenSSL nie wybiera automatycznie DHE, ale może to być wywołanie zwrotne aplikacji. OpenSSL 1.0.2 (styczeń 2015) może opcjonalnie automatycznie wybrać ECDHE , a także w 1.0.2 s_clientzawsze wyświetla „Klucz serwera temp” DH i rozmiar lub ECDH i krzywą, jeśli dotyczy, tuż przed „handshake odczytał x i napisał y”, więc nie potrzebujesz już rozszyfrować. Najnowszy mod_ssl Apache, który automatycznie wybiera DHE: httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslcertificatefile (który zwraca uwagę na problem dotyczący klientów Java).
dave_thompson_085
Używam openssl 1.0.1e i nie mam nic ServerKeyExchangez 0c 00 03 0b. czy możesz podać dokładne polecenie, aby uzyskać wynik? Nie mam żadnego 0c
uścisku
Jeśli pakiet szyfrów wybrany przez serwer nie jest pakietem szyfrów „DHE” lub „ECHDE”, komunikat ServerKeyExchange nie zostanie wyświetlony.
Thomas Pornin
Dostaję <<< TLS 1.2 Uzgadnianie [długość 01cd], ServerKeyExchange 0c 00 01 c9 03 00 17 41 04 08 5f 82 88 1e e5 b6, a następnie 443 oktety, które odpowiadają długości 0x1c9, zaczynając od piątego oktetu. Jednak „0300” wydaje się oznaczać 768 oktetów, podczas gdy jestem pewien, że mój parametr DH ma „tylko” 2048 bitów.
Law29
1
@ Law29 To bardziej przypomina ECDHE ServerKeyExchange. Jeśli używasz krzywej eliptycznej, wówczas „03” oznacza „to jest nazwana krzywa, następne dwa bajty kodują identyfikator krzywej”. Zatem „00 17” jest identyfikatorem krzywej, którym jest NIST P-256 (najczęściej stosowana krzywa dla ECDHE). Zatem „41” oznacza długość punktu publicznego, która jest dokładnie właściwą wartością dla punktu P-256 w nieskompresowanym formacie; taki punkt zaczynałby się od bajtu o wartości 0x04 i właśnie to masz. Podsumowując: wygląda na to, że uścisk dłoni TLS 1.2 naprawdę używa ECDHE, a nie DHE.
Thomas Pornin
9

Jeśli masz certyfikat w formacie PEM, możesz wypróbować to polecenie, powinno ono dać ci prawidłowe wyjście z polecenia openssl.

openssl dhparam -inform PEM -in ./imapd.pem -check -text

(Próbka wyjściowa)
    Parametry PKCS # 3 DH: (512 bitów)
        główny:
            xx: xx: xx: xx
            xx: xx: xx: xx
            xx: xx: xx: xx
        generator: 2 (0x2)
Parametry DH wydają się być w porządku.
----- ROZPOCZNIJ PARAMETRY DH -----
XXXX
XXXX
----- KONIEC PARAMETRÓW DH -----

Mam nadzieję, że tego właśnie szukasz.

David Loh
źródło