Connessione TLS a server non attendibili: reazione del client per il rilascio della connessione standardizzata?

5

Ho giocato con uno strumento proxy man-in-the-middle e ho collegato diversi smart phone ad esso. Poiché il proxy utilizza un certificato autofirmato, le app per smartphone testate non hanno accettato il certificato del server presentato.

La parte interessante (dal mio punto di vista) era che diverse piattaforme di smartphone utilizzavano messaggi e strategie totalmente diversi per assicurarsi che la connessione TLS non possa essere stabilita.

Alcuni hanno appena inviato un messaggio ALERT con la descrizione bad_certificate (42) o certificate_unknown (46). Altri telefoni hanno continuato la stretta di mano, ma in seguito lo scambio di chiavi è fallito in modo deterministico.

Ho trovato particolarmente interessante l'ultimo caso in quanto non è chiaro in che modo il client forza la fase di handshake a fallire e se un server / proxy adattato può ancora essere in grado di "salvare" la fase di handshake e stabilire la connessione ...

Le azioni che un client deve eseguire in un punto scritto in un RFC per interrompere la connessione nel caso in cui sia stato rilevato un certificato non attendibile?

Se no, qualcuno sa quale meccanismo viene solitamente utilizzato per sabotare volontariamente la fase di handshake TLS?

    
posta Robert 31.03.2015 - 09:31
fonte

1 risposta

-1

La convalida del certificato X509 è inclusa nella RFC 5280.

Guarda la sezione 6 ( link )

Conforming implementations of this specification are not required to implement this algorithm, but MUST provide functionality
equivalent to the external behavior resulting from this procedure.

    
risposta data 24.04.2016 - 03:53
fonte

Leggi altre domande sui tag