La risposta letterale è no: TLS non accetta messaggi non crittografati. Tuttavia, le preoccupazioni del collega non sono infondate. Non so se è confuso, ma casualmente si è imbattuto in una vera preoccupazione, o ha capito i problemi ma li ha spiegati in modo molto confuso.
Una connessione TLS è sempre crittografata (quindi un man-in-the-middle non può leggere i dati trasmessi) e protetta dall'integrità (quindi un man-in-the-middle non può modificare i dati trasmessi¹). Sebbene la specifica TLS definisca una cipher suite "nullo", la maggior parte delle applicazioni non la userà, e non tutte le librerie TLS la hanno anche autorizzata. A meno che non si attivi per abilitarlo sia sul client che sul lato server, la cipheruite null non si verificherà. Ogni altra suite ha crittografia e protezione dell'integrità.
La sicurezza di TLS si basa anche sulle due parti, assicurandosi che stiano parlando direttamente l'una con l'altra. Non ci sarebbe alcuna sicurezza se tutto ciò accadesse fosse che il client legittimo ha una connessione sicura con il man-in-the-middle, e il man-in-the-middle ha una connessione sicura con il server legittimo. Il modo in cui questo funziona sul Web (e nella maggior parte degli altri usi di TLS) è che il client autentica il server verificando che il certificato del server sia valido. Non entrerò in ciò che "valido" significa qui; in poche parole, il certificato deve essere crittograficamente coerente con la connessione (il client lo verificherà sempre) e deve essere firmato da un'autorità di certificazione che il cliente si fida (questo bit è un po 'più fragile, ma funzionerà si utilizza un software ragionevolmente aggiornato e si configura correttamente il server).
Come al solito, tutto ciò è soggetto al mantenimento degli aggiornamenti di sicurezza nel software e alla sua corretta configurazione. Alcune versioni precedenti del protocollo sono state interrotte, ovvero non offrono le garanzie che sono state progettate per offrire. Ma finché non esegui software obsoleti o abiliti funzioni obsolete nella configurazione del server, le cose vanno bene.
Quindi a cosa potrebbe riferirsi il tuo collega?
someone, someday, will forget to encrypt a message, expose their session token/user identity/whatever, and leave themselves open to a man-in-the-middle attack
Questo può accadere anche se il tuo server supporta TLS. Un client potrebbe inviare una richiesta HTTP anziché HTTPS. Quindi un utente malintenzionato potrebbe impersonare il server e visualizzare i dati inviati dal client su HTTP. Non c'è nulla che il server possa fare per impedirlo completamente, ma ci sono cose che puoi fare per renderlo principalmente un problema di moot.
La prima cosa da fare è solo dare agli URL degli utenti che iniziano con https:// . Ciò non aiuta se qualcuno digita direttamente l'URL.
Un lato della medaglia è configurare il tuo server in modo che non risponda a HTTP, tranne che per reindirizzare al sito HTTPS. In altre parole, tutti i servizi sulla porta 80 sono reindirizzamenti a https://same remainder of the URL . Inoltre, comunica al cliente che devono utilizzare HTTPS direttamente la volta successiva, abilitando la HSTS nella configurazione del tuo server. HSTS fa in modo che il server invii al client un'istruzione per utilizzare sempre HTTPS per un determinato sito in futuro. In questo modo solo la prima connessione da un particolare client potrebbe essere in chiaro.
L'altro lato della medaglia è quello di proteggere i dati riservati dall'essere inviati tramite HTTP. Non puoi proteggere le credenziali dell'utente se insistono nel mandarle in chiaro, proprio come non puoi impedire ad un utente di aprire la loro finestra e gridare la loro password a tutti per la strada. Ma puoi proteggere i cookie utilizzati dall'applicazione: assicurati che tutti i tuoi cookie hanno il flag secure . In questo modo, se l'utente ottiene in qualche modo il proprio browser per effettuare una connessione HTTP, il browser non invierà i cookie.
¹ Eccezione: un mitm può forzare la chiusura della connessione a metà strada. Questo è in linea di principio visibile perché ciò accade a livello di TCP e entrambe le parti possono dire che il livello TLS non è stato correttamente terminato (da un avviso fatale), ma le applicazioni come i browser in genere non forniscono alcun feedback su questo, ed è indistinguibili dai problemi di rete che si verificano.