¿Cuáles son algunos de los riesgos prácticos que conlleva una conexión de servidor a servidor a través de http (no está protegido con https / SSL)? No hay usuarios involucrados, solo una conexión de servidor a servidor de una compañía a otra.
Business A llamará a un punto final del servicio web en Business B. Se incluirá una clave de API en la llamada que se usará para acceder a la puerta de acceso (por ejemplo, la clave debe ser válida y estar en buen estado).
Sé que es posible detener el tráfico. No estoy seguro de que esto sea probable , solo posible. ¿Cómo se explica uno por el riesgo asociado?
¿Cuáles son otros riesgos prácticos?
EDITAR: para un contexto adicional, algunas API web públicas admiten llamadas basadas en http con clave pasada en carga o URL. Por ejemplo: Posterous, Tumblr (la nueva API admite OAuth sobre http), Bing, GoodGuide y Flickr.
EDIT 2 17-Mar-2014: Hace dos años planteé esta pregunta. Se debió principalmente a mi curiosidad sobre los vectores de ataque reales en situaciones de servidor a servidor, ya que la mayor parte de la visibilidad se relaciona con los ataques del usuario final o la piratería en los servidores. Pero rara vez he escuchado "¡si solo hubiéramos usado SSL de servidor a servidor!" (aunque sí recuerdo una excepción, la violación TJX 2006 - donde las tarjetas de crédito fueron robadas de un canal wifi sin garantía, supongo http dentro de él (aunque wifi es su escenario no típico de servidor a servidor).
No es que no entienda o sepa cómo usar SSL (lo hago, lo uso y entiendo el criptográfico que hay detrás), por lo que esto no es ignorancia del conjunto de herramientas. Hasta ahora, nadie ha considerado que las API web que enumero más arriba puedan usarse para comprometer datos confidenciales (una foto privada en Flickr, publicando contenido malicioso en mi cuenta en Tumlbr (¡Posterous ya no está!), Accediendo a mi personal ( podría ser muy privado) consultas de búsqueda en Bing y GoodGuide).
Dado que la complejidad de ofrecer APIs a través de HTTPS cae completamente en el servicio, es fácil elegir HTTPS como cliente (aunque, en el escenario de interés aquí, el "cliente" es otro servidor) - Supuse que el Los proveedores que produjeron las API enumeradas anteriormente evaluaron cuidadosamente los pros y los contras y decidieron que permitir HTTP era correcto.
Estoy de acuerdo en que en cualquier momento en que estemos a cargo de los datos confidenciales o confidenciales de los usuarios finales o de la compañía, tenemos el deber fiduciario implícito de tratarlo de manera responsable (ya sea producción, desarrollo o prueba, si merece protección) . Pero esto no es todo escenario (de nuevo, es por eso que planteé esta pregunta).
Aquí hay algunas ventajas y desventajas que pueden venir a la mente en el caso general.
Google Maps tiene una clave de API que debe exponer en público (reside en JavaScript) y el acceso al servicio se puede bloquear con el nombre de dominio de alojamiento (encabezado REFERER), por lo que no es necesario (y no requiere) SSL. (Esto se usa más comúnmente en un modelo de usuario final a servidor, pero al menos es posible pensar esto en un escenario de servidor a servidor. Todos podemos entender la lógica al menos).
Además, las instancias de desarrollo y prueba de muchos servicios que ofrecen están mejor sin SSL. Son más fáciles de depurar en el cable cuando el tráfico no está cifrado. Además, es muy doloroso configurar certificados SSL para la mayoría de los entornos, ya que a menudo tendrán ad hoc nombres de dominio siempre cambiantes en los puntos finales a medida que los entornos van y vienen, tal vez ni siquiera son lo suficientemente consistentes para un certificado de comodín.
También hay escenarios de servidor a servidor que son menos vulnerables que otros, incluso si se están transmitiendo datos confidenciales. Por ejemplo, considere los servidores que pertenecen a diferentes divisiones dentro de la misma compañía, y los datos no viajan a través de la Internet pública (por ejemplo, rango de direcciones 192.168).
Como otro ejemplo, considere los servidores que se ejecutan en una plataforma de nube pública (por ejemplo, Amazon o Azure). No creo que pueda tener problemas con otros servidores que se ejecutan en la misma región del centro de datos porque no hay código (aparte de la plataforma del host) tendrá la capacidad de elevar los permisos en el hipervisor para configurar la tarjeta NIC en modo promiscuo para interceptar el tráfico (e incluso si pudiera, no podría verlo a través del hipervisor (creo), e incluso si pudiera solo podía detener el tráfico dentro de su propia red VNET).