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?