Valore della curva con nome 0xffff nel messaggio "Server Hello"

2

Sto usando il provider JCE RS2 BSAFE Crypto-J 6.2 in Java come server SSL / TLS (in modalità FIPS 140 Compliant per SunJSSE).

Sembra che almeno Chrome e Firefox non possano stabilire una connessione se viene utilizzato TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 ( 0xc02b ).

L'errore in Firefox durante la connessione al server è: " sec_error_unsupported_elliptic_curve "

Con il messaggio di errore come suggerimento ho guardato nell'handshake (usando Wireshark). Nel "Client Hello" vedo 3 curve:

Elliptic curve: secp256r1 (0x0017)
Elliptic curve: secp384r1 (0x0018)
Elliptic curve: secp521r1 (0x0019)

Nel messaggio "Server Hello" corrispondente, vedo il valore della curva con nome 0xffff

Named Curve: Unknown (0xffff)

Di conseguenza, il browser interrompe la connessione con il messaggio di errore sopra indicato.

Se utilizzo Java standard sul lato server (nessun provider BSAFE Crypto-J) la curva denominata nel "Server Hello" è:

Named Curve: secp256r1 (0x0017)

... e l'handshake termina con successo.

  1. La domanda ora è, qual è il significato se 0xffff ? Significa che il server non comprende l'insieme di curve suggerito dal client? Ho esaminato la sezione 5.1.1 di RFC4492 ma non ho trovato nulla sul valore di 0xffff
  2. Se qualcuno ha esperienza con RSA BSAFE Crypto-J e Java in esecuzione in modalità FIPS. Qualcun altro che si è imbattuto in quel problema e ha trovato una soluzione.
posta Cris 19.08.2015 - 15:52
fonte

3 risposte

1

The question now is, what is the meaning if 0xffff? Does it mean that the server does not understand the set of curves suggested by the client?

Non penso che significhi ufficialmente questo. Ma ho la sensazione che l'implementazione lo stia facendo ancora con questa intenzione.

Non assegnato a IANA

L'identificatore 0xFFFF (65535 decimale) è contrassegnato come Unassigned nel registro IANA ufficiale .

Questo significa anche che NON è Reserved o contrassegnato come speciale in nessun altro modo.

Re. definizione enum

L'RFC TLS 1.2 contiene una definizione della sintassi per l'enumerazione:

RFC 5246 - Protocollo TLS (Transport Layer Security), versione 1.2 , sezione 4.5 Enumerati :

One may optionally specify a value without its associated tag to
force the width definition without defining a superfluous element.

In the following example, Taste will consume two bytes in the data
stream but can only assume the values 1, 2, or 4.

   enum { sweet(1), sour(2), bitter(4), (32000) } Taste;

Sto leggendo RFC4492 Sezione 5.1.1 per indicare la stessa cosa.

    
risposta data 20.08.2015 - 09:07
fonte
2

Guarda RFC4492 Sezione 5.1.1 che menzioni nel tuo post, vediamo il seguente struttura:

enum {
        sect163k1 (1), sect163r1 (2), sect163r2 (3),
        sect193r1 (4), sect193r2 (5), sect233k1 (6),
        sect233r1 (7), sect239k1 (8), sect283k1 (9),
        sect283r1 (10), sect409k1 (11), sect409r1 (12),
        sect571k1 (13), sect571r1 (14), secp160k1 (15),
        secp160r1 (16), secp160r2 (17), secp192k1 (18),
        secp192r1 (19), secp224k1 (20), secp224r1 (21),
        secp256k1 (22), secp256r1 (23), secp384r1 (24),
        secp521r1 (25),
        reserved (0xFE00..0xFEFF),
        arbitrary_explicit_prime_curves(0xFF01),
        arbitrary_explicit_char2_curves(0xFF02),
        (0xFFFF)
    } NamedCurve;

Mi sembra che 0xFFFF sia un valore riservato che è (forse erroneamente?) inviato per indicare che il server non supporta ECC, o per indicare la fine della matrice di curve.

È possibile che il provider BSAFE Crypto-J non sia configurato correttamente.

    
risposta data 19.08.2015 - 19:37
fonte
-1

Ho avuto lo stesso identico problema, tutto funzionava con Java 7 e quando ho aggiornato JRE a Java 8, ho iniziato a ricevere questo errore sec_error_unsupported_elliptic_curve .

Ho risolto il problema impostando il parametro JVM com.sun.net.ssl.enableECC in false

-Dcom.sun.net.ssl.enableECC = false

    
risposta data 07.12.2015 - 09:30
fonte

Leggi altre domande sui tag