Usando la porta SSL (443) per il traffico non SSL, idea sbagliata?

Question

Usando la porta SSL (443) per il traffico non SSL, idea sbagliata?

#1 da (1 voti)

0

Abbiamo una webapp che è stata creata per usare SSL per determinati (ma non per tutti) tipi di richieste. La webapp utilizza più sottodomini, il numero può cambiare. Questa combinazione di funzionalità fa sì che l'applicazione web richieda un certificato SSL con caratteri jolly.

La webapp è usata da alcune persone, ma non da molte di esse. Vorremmo mantenere attiva la webapp per coloro che la utilizzano, ma è stato stabilito che, al momento, non è economicamente giustificabile pagare il certificato con caratteri jolly.

Poiché la webapp non ha alcun metodo build-in per eliminare il requisito SSL (o più precisamente, la webapp si aspetta che il "traffico SSL" entri attraverso un vhost separato che ascolta lo stesso sottodominio), ho pensato che il la soluzione più semplice sarebbe semplicemente disabilitare il protocollo SSL e mantenere il traffico (non crittografato) in esecuzione sulla porta 443.

La mia grande domanda è:
è una cattiva idea eseguire il traffico non SSL sulla porta 443 (e perché)?

tls

posta Monika 11.10.2014 - 16:42

fonte

1 risposta

Leggi altre domande sui tag tls

la firma digitale è vulnerabile su Internet? cd-rom distro - più un'ulteriore validazione

score 1 · Accepted Answer

Questo non mi sembra molto facile. I client (e presumo che stiamo parlando di browser qui) si aspettano che il traffico http venga servito sulla porta 80 e il traffico https su 443. Per cambiare questo indirizzo su http su 443, è necessario che tu modifichi lo schema URL in http, quindi specificare esplicitamente la porta su ciascun URL.

Quindi, per un URL https come questo: https://example.com/some-resource dovrai cambiarlo in: http://example.com:443/some-resource .

Mi sembra che se si desidera rimuovere il requisito SSL, sarebbe più semplice lasciare http in esecuzione sulla porta 80 in modo che l'unica modifica che si deve apportare ai propri URL sia quella di rimuovere s dallo schema .

Se ti stai chiedendo se puoi servire il traffico http direttamente a un client che sta facendo una richiesta https, permettendoti di lasciare l'URL lo stesso, no, non dovrebbe funzionare. Il client sta tentando di avviare un handshake TLS e quando non riceve una risposta TLS, la connessione avrà esito negativo.