No puede verificar fallas de implementación. Lo que puedes ver de un cliente son:
-
Uso de protocolos débilmente débiles. Al verificar que el servidor admita TLS 1.1 y 1.2, ya lo está descartando.
Falta de adecuación flagrante . Por ejemplo, si la clave pública del servidor (vista en el certificado del servidor) es demasiado pequeña para la seguridad (por ejemplo, una clave RSA de 512 bits). O si observa que el "aleatorio" del servidor es siempre el mismo.
Esto invierte la carga de la prueba . Normalmente, una implementación determinada debe proactivamente esforzarse por demostrar que hace las cosas correctamente, explicando (por ejemplo), en su documentación, que se han seguido las reglas de desarrollo adecuadas al implementar. Esto puede ser tan simple como decir "usamos LibfoobarSSL versión 42.17", pero debe haber algún tipo de documentación. No es su trabajo "validar" la implementación contra fallas; es bien sabido que tal validación ciega a posteriori no funciona. Puede notar los agujeros más deslumbrantes, pero no encontrar nada no significa que no haya nada que encontrar.
Como ejemplo, alrededor de 1996, la implementación de SSL en Netscape (el navegador web líder en ese momento) fue débil debido a una muy mala PRNG : las pruebas estadísticas no pudieron mostrar el problema, ya que se trataba de mala siembra : la mayor parte del estado interno del PRNG era predecible, por lo que era una cuestión de Pocos segundos para descifrar cualquier túnel SSL, pero las pruebas estadísticas no habrían mostrado nada mal. La detección de ese defecto requirió ingeniería inversa . Esto no se puede automatizar con una herramienta.