A raíz del fallo Heartbleed, muchos se enfrentan a la desalentadora (y costosa) perspectiva de sustituir los certificados SSL en aquellos sistemas vulnerables. Esto se debe a la posibilidad de que las claves privadas de los certificados SSL expuestos puedan o no haber sido comprometidas. Al final, como no hay forma de saber con seguridad si sus claves privadas se han visto comprometidas, muchos están optando por sustituir los certificados SSL del sistema o sistemas afectados.
Pero, ¿es estrictamente necesario utilizar costosos certificados de raíz pública para todas sus necesidades de certificados en SSL ? En muchos casos, la respuesta es sin duda afirmativa. Pero no siempre es así.
En mi carrera como consultor de PKI, a menudo me he encontrado con certificados de raíz pública SSL utilizados en lugares donde los certificados de raíz privada habrían sido sin duda suficientes. La decisión de utilizar certificados arraigados públicamente se toma por diversas razones: percepción de niveles elevados de fiabilidad y seguridad y conveniencia empresarial, por citar algunas. Los administradores suelen tomar la decisión de utilizar certificados públicos porque "siempre se ha hecho así".
Tal vez este acontecimiento del fallo Heartbleed pueda servir para revisar algunas de esas decisiones.
En mi opinión, la decisión de utilizar un certificado de raíz pública debería basarse en los requisitos de PKI de la aplicación SSL . La decisión no debe basarse en "FUD" (miedo, incertidumbre y duda), ni en la inercia empresarial, ni mucho menos en conceptos erróneos.
Y digo "deberían" porque muchas veces he comprobado que los requisitos de PKI de la aplicación no son los principales impulsores de este proceso de decisión. Los administradores a cargo de las aplicaciones a menudo toman la decisión de utilizar certificados con raíz pública en lugar de certificados con raíz privada basándose en la percepción (errónea) de que los certificados con raíz pública de SSL son de alguna manera más fiables, o de alguna manera tienen más garantías que cualquier certificado de SSL que pudieran generar de forma privada. Y aunque puede que sea así, todos hemos visto casos en los que no lo es.
He formado parte de muchos esfuerzos de diseño de PKI de raíz privada que han dado lugar a PKI corporativas capaces de ofrecer niveles de garantía excepcionalmente altos, cuyos certificados están totalmente documentados por su CP/CPS y validados por auditores externos. Por el contrario, todos hemos leído recientemente en las noticias sobre las deficiencias de confianza de algunas PKI muy públicas.
Como puede ver, es totalmente plausible que la PKI existente de un administrador pueda proporcionar una garantía más que suficiente para las necesidades de sus certificados SSL , a menudo a un coste significativamente inferior. Así pues, ¿en qué debe basarse un administrador encargado de renovar su certificado SSL para tomar una decisión "pública/privada"? La respuesta suele reducirse a la "confianza" en el certificado, y no a la "seguridad". Es decir, ¿quién necesitará confiar en su certificado? ¿Y desde dónde deberá establecerse esa confianza?
Como propietario de una aplicación, uno debe saber quién necesita confiar en su certificado SSL . Es decir, ¿quién utilizará los certificados? ¿Teléfonos móviles? ¿Ordenadores portátiles de empresa? ¿Vendedores? ¿El público?
Si la respuesta a la pregunta sobre la confianza es una lista de entidades sobre las que no se tiene absolutamente ningún control informático, entonces no se puede asumir que habrá confianza alguna en su certificado CA raíz privado. Esto requerirá casi con toda seguridad que su nuevo certificado SSL se arraigue públicamente.
Pero, si la respuesta a esa pregunta de confianza es una lista de entidades sobre las que tiene un control informático completo, como ordenadores portátiles, servidores y usuarios corporativos, entonces existe una gran posibilidad de que estas entidades ya confíen o puedan confiar en su raíz privada. Esto significa que tienes la gran posibilidad de utilizar un certificado SSL con raíz privada.
Vale la pena considerar, mientras todos lidiamos con las secuelas del fallo Heartbleed, un enfoque nuevo y posiblemente refinado para reemplazar los certificados afectados. Quizás puedas utilizar tus propios certificados de SSL .
