Come posso supportare il traffico SSL e non SSL sulla stessa porta utilizzando TIdTCPServer e OpenSSL in Delphi XE3?

Question

Sto provando a configurare un server Web in Delphi XE3 utilizzando Indy e OpenSSL che possono servire il traffico su entrambe le connessioni HTTP e HTTPS sulla stessa porta.

Ho visto due approcci principali a questo, e nessuno dei due sembra funzionare per me.

Primo: TLS up-front/SSL. Ciò comporta la lettura dei primi byte dello stream per cercare la parte "Client-Hello" dell'handshake non sicuro e (se trovato) che richiama la risposta handshake SSL del server, ma se lo faccio, la libreria OpenSSL non riconosce la stretta di mano perché mi sono tolto i byte principali del messaggio.

Secondo: TLS dopo STARTTLS (o equivalente). Ciò comporta l'invio di un set speciale di caratteri (STARTTLS) che sarà immediatamente seguito da "Client-Hello". Il server lascia quindi intatto l'intero messaggio SSL handshake per passare alla libreria OpenSSL. Il problema con questo approccio è che la maggior parte dei browser Web non la supportano (RFC 2817).

Per una sintesi dei due approcci, guarda qui: What happens on the wire when a TLS/LDAP or TLS/HTTP connection is set up?)

Come posso supportare il traffico SSL e non SSL sulla stessa porta utilizzando TIdHTTPServer e OpenSSL in Delphi XE3?

Answer 1

Quello che chiedi non è possibile con Indy out of the box. La sua implementazione SSL predefinita utilizza l'API tradizionale di OpenSSL dove fa tutto il proprio I/O del socket, quindi ha bisogno di un accesso diretto ai dati completi dell'handshake senza prima dare un'occhiata ai dati. Tuttavia, non tutto è perduto. Hai un paio di scelte:

1) usa libpcap/Winpcap per catturare e guardare i primi pochi byte di dati grezzi che escono dal filo per nuove connessioni prima che il socket lo fornisca alla tua applicazione.

2) scrivi la tua classe derivata TIdIOHandler che utilizza l'API BIO più recente di OpenSSL o l'API di SChannel di Microsoft, così puoi controllare l'I/O del socket e leggere i byte in ingresso e guardarli prima di inserirli nel motore di crittografia per l'elaborazione.

Answer 2

Non mi aspetto che questo sia così facile da implementare con Internet Direct (Indy) - il server Apache HTTP non può farlo, e questo significa che a) quasi nessuno ha mai voluto questa caratteristica b) non è così facile implementare o forse c) potrebbe introdurre rischi per la sicurezza.

Dalla risposta accettata a https://serverfault.com/questions/359461/apache-answer-both-http-and-https-on-the-same-port

Questo non sta per essere possibile con Apache. Con Apache non è possibile che abbia HTTPS e HTTP in esecuzione sulla stessa porta.

Sono a conoscenza di alcuni port-multiplexer progettati per rendere HTTPS/OpenVPN o SSH eseguiti sulla stessa porta, ma questi richiedono software aggiuntivo. I non sono a conoscenza di strumenti che eseguiranno il multiplex HTTPS e HTTP.