Tre delle risposte attualmente fornite richiedono abbassare il livello di sicurezza del tuo browser , lasciando probabilmente aperto a vari attacchi se lo fai nel tuo browser principale, successivamente usa quel browser per altri siti web, o semplicemente dimentica di annullare questa modifica (o più modifiche).
Funzionalità SSL / TLS legacy e non protette (SSLv2 e SSLv3 , firme SHA1RSA, RC4 e crittografie 3DES, MD5 MAC, esportazione cipher, non PFS ciphers, < 1024 parametri DH) sono progressivamente disabilitati per impostazione predefinita e / o rimossi dai browser, e per una buona ragione.
Un problema a parte che @AndreKR segnala in modo utile è la compatibilità del browser , nel qual caso un browser legacy in una VM dedicata è probabilmente la soluzione più affidabile.
Se non puoi sostituire il dispositivo, usa VM dedicata o un browser dedicato. La prossima opzione migliore è un proxy TLS per consentire l'uso di un browser sicuro contemporaneo. Abilitare una, (o due, tre ...) funzionalità non sicure in un browser non è una soluzione sicura e sostenibile, e quando accade l'inevitabile e una funzionalità richiesta viene completamente rimossa? (Supporto SSLv3 per Chrome , Opera , Firefox ).
Un'alternativa sicura consiste nel proxy delle connessioni attraverso qualcosa che supporti sia vecchio / legacy sia nuovi protocolli & cifre, ci sono molte opzioni (inclusa la soluzione piuttosto pesante di un proxy inverso Apache).
La seguente soluzione più leggera dovrebbe funzionare su entrambi i sistemi * nix e Windows. Ciò richiederà la generazione di una chiave / certificato - non necessariamente un problema poiché la prossima cosa che succederà è che i browser contemporanei rifiuteranno i certificati firmati SHA1. In questo modo è possibile utilizzare un certificato RSA-2048 firmato SHA-2 e un TLS contemporaneo per l'accesso al dispositivo.
Per questo esempio:
Il dispositivo - si trova su 192.168.1.123 con HTTPS sulla porta predefinita
- funziona come mostrato su * nix, entrambe le opzioni sono supportate su Windows e dovrebbero richiedere modifiche minime
- hai generato una chiave / certificato per l'uso, utilizzando uno di questi se necessario:
proxy socat
Utilizzo di socat :
CERT="cert=mydevice.crt,key=mydevice.key"
SSLSRV="cipher=AES256-SHA,method=TLS1.2,verify=0"
SSLCLI="cipher=AES128-SHA,method=SSL3,verify=0"
socat \
OPENSSL-LISTEN:11443,bind=127.0.0.1,reuseaddr,fork,$CERT,$SSLSRV \
OPENSSL:192.168.1.123:443,$SSLCLI
e connettiti a https://127.0.0.1:11443/
Note
Modifica il tuo file hosts locale per prevenire gli avvisi di mancata corrispondenza del nome del certificato, se necessario, poiché è necessario un certificato interno per questo comunque puoi generare un certificato con il nome interno previsto (a differenza di molti dispositivi che ho riscontrato tendono ad usare nomi strani o ostili per i certificati).
Per il supporto TLSv1.2 è necessario OpenSSL-1.0.1 o successivo e socat-1.7.3.0 o successivo. Le opzioni cipher e method possono essere regolate in base ai requisiti, così come la verifica del certificato del server o del client.
Questa soluzione si estende anche a problemi simili, come i dispositivi solo SSLv2, o con certificati a 512 bit o un insieme di cipherità cifrate, sebbene sia necessario assicurarsi che OpenSSL non sia stato creato con no-ssl2 o no-ssl3 e ha attivato la cipheruite pertinente.
Se fossi un auditor preferirei vedere un metodo di accesso documentato (insieme a un piano di aggiornamento!) piuttosto che una soluzione ad hoc che è un incidente che aspetta di accadere.
