Tres de las respuestas contribuidas actualmente requieren reducir el nivel de seguridad de su navegador , posiblemente dejándolo abierto a varios ataques si lo hace en su navegador principal, luego use ese navegador para otros sitios web, o simplemente olvide revertir este cambio (o varios cambios).
Funciones SSL / TLS heredadas e inseguras (SSLv2 y SSLv3 , firmas SHA1RSA, RC4 y cifrados 3DES, MD5 MAC, exportar los cifrados, los cifrados que no son PFS, < 1024 parámetros DH) están progresivamente desactivados de forma predeterminada y / o eliminados de los navegadores, y por buenas razones.
Un problema aparte que @AndreKR identifica de manera útil es el de compatibilidad de navegador , en cuyo caso, un navegador heredado en una máquina virtual dedicada es probablemente la solución más robusta.
Si no puede reemplazar el dispositivo, use una máquina virtual dedicada o un navegador dedicado. La siguiente mejor opción es un proxy TLS para permitir el uso de un navegador seguro contemporáneo. ¿Habilitar una, (o dos, o tres ...) características inseguras en un navegador no es una solución segura y sostenible, y cuando sucede lo inevitable y se elimina por completo una característica requerida? (Compatibilidad de SSLv3 con Chrome , Opera , Firefox ).
Una alternativa segura es hacer proxy de las conexiones a través de algo que admita tanto los protocolos antiguos / heredados como los nuevos y amp; cifrados, hay muchas opciones (incluida la solución bastante pesada de un proxy inverso Apache).
La siguiente solución más liviana debería funcionar en los sistemas * nix y Windows. Esto requerirá que genere una clave / certificado, no necesariamente un problema, ya que lo siguiente que sucederá es que los navegadores contemporáneos rechazarán los certificados firmados por SHA1. De esta manera, puede utilizar un certificado RSA-2048 firmado por SHA-2 y un TLS contemporáneo para acceder al dispositivo.
Para este ejemplo:
- el dispositivo está en 192.168.1.123 con HTTPS en el puerto predeterminado
- funciona como se muestra en * nix, ambas opciones son compatibles con Windows y deben requerir cambios mínimos
- usted ha generado una clave / certificado para su uso, utilizando uno de estos si es necesario:
socat proxy
Utilizando 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
y conéctate a https://127.0.0.1:11443/
Notas
Si es necesario, modifique su archivo hosts local para evitar advertencias de emparejamiento de nombre de certificado desde su navegador, ya que de todos modos necesita un certificado interno para esto, puede generar un certificado con el nombre interno esperado (a diferencia de muchos dispositivos con los que me he encontrado). tienden a usar nombres extraños o antipáticos para los certificados).
Para el soporte TLSv1.2 necesitará OpenSSL-1.0.1 o posterior, y socat-1.7.3.0 o posterior. Las opciones cipher y method se pueden ajustar según los requisitos, al igual que la verificación del certificado del servidor o del cliente.
Esta solución se extiende incluso a problemas similares, como dispositivos con SSLv2 solamente, o con certificados de 512 bits o un conjunto de conjuntos de cifrado, aunque deberá asegurarse de que OpenSSL no se haya creado con no-ssl2 o no-ssl3 y tiene el conjunto de cifrado relevante habilitado.
Si fuera un auditor, preferiría ver un método de acceso documentado (¡junto con un plan de actualización!) que una solución ad hoc que es un accidente que está por suceder.
