Protocolo propietario. Software propietario. Comparación de tecnologías y protocolos de acceso seguro
La principal diferencia entre los reproductores de audio portátiles de la “generación de Internet” y sus predecesores es su estrecha integración con una computadora personal.
En el pasado, los reproductores portátiles reproducían música desde medios extraíbles comunes y no necesitaban estar conectados a nada más que a unos auriculares.
Hasta hace poco, la PC era su única fuente de contenido. Al mismo tiempo, se necesitaba un mecanismo para emparejar un reproductor portátil y una computadora. La tarea consistía en transferir datos en formato digital de un medio (en una PC) a otro (en un reproductor) en un formato aceptado en la industria informática.
El contenido debe transferirse desde el ordenador, donde suele almacenarse en un disco duro de 3,5", a reproductores multimedia portátiles: memoria flash, discos duros de 1" y 1,8".
Por lo tanto, se debe utilizar algún tipo de interfaz de datos informáticos.
En cualquier interfaz de este tipo se pueden distinguir dos niveles. El primero es físico, es decir. directamente cables, conectores, microcircuitos, etc. El segundo es el software, que es, relativamente hablando, un conjunto de instrucciones y algoritmos según los cuales se intercambian datos a nivel físico. Esta capa de software a menudo se denomina protocolo. Hoy hablaremos principalmente de ello. Para el usuario, es la “cara” de la interfaz, sus capacidades y desventajas determinan la conveniencia o dificultad de operar el dispositivo en su conjunto.
Para operar completamente el protocolo, se requieren dos componentes de software. En primer lugar, se trata de un controlador que conecta directamente un dispositivo portátil y una PC a nivel de software. En segundo lugar, esto software, permitiendo al usuario gestionar el protocolo y utilizarlo según sus necesidades. El software, estrictamente hablando, no forma parte directa del protocolo. Pero sin su presencia, la existencia misma del protocolo pierde sentido. Por lo tanto, en este artículo consideraremos el software como una parte integral de los protocolos considerados.
Cualquier protocolo de software utiliza controladores y software, aunque la implementación de estos componentes en cada caso concreto puede variar mucho. El éxito del protocolo se puede calcular aproximadamente mediante la fórmula: oportunidades menos inconvenientes. Las capacidades se refieren a la gama de funciones disponibles. Las desventajas suelen incluir opacidad de uso, instalación incómoda, dificultad de aprendizaje y compatibilidad limitada.
Según los estándares de la tecnología digital portátil, los reproductores MP3 ya son una clase de dispositivos bastante antigua. Aparecieron en un momento en que la infraestructura de la PC no estaba en absoluto preparada para el papel de la computadora como host multimedia. Tanto a nivel físico como de software, no existían soluciones generalizadas y estandarizadas en esta área; solo estaban en desarrollo, preparándose para ingresar al mercado, o existían en cantidades individuales. Otras clases relacionadas de dispositivos portátiles se encontraron en una situación similar: dispositivos de almacenamiento móviles, cámaras digitales, teléfonos celulares, PDA. Todos estos tipos de tecnología móvil aparecieron aproximadamente al mismo tiempo, en la segunda mitad de los años 90. Su aparición requirió el desarrollo de protocolos estándar unificados para emparejar PC con equipos portátiles.
A nivel físico todo estaba relativamente claro. Los primeros dispositivos portátiles se vieron obligados a utilizar COM y LPT; en ese momento simplemente no había otras interfaces ampliamente disponibles.
El conector LPT todavía se puede encontrar en la mayoría de las PC.
Así, fue la interfaz física LPT la que utilizaron los fundadores de los reproductores MP3, Saehan MpMan y Diamond Rio. Este período se puede llamar "artesanía"; los desarrolladores tuvieron que utilizar interfaces y protocolos que fueron creados originalmente para tareas completamente diferentes.
Sin embargo, la nueva generación de audio portátil no tuvo que sufrir por mucho tiempo las cadenas de interfaces lentas e incómodas: ya en 1999, los fabricantes introdujeron una amplia gama de dispositivos que utilizaban el nuevo estándar: USB, Universal Serial Bus.
Durante algún tiempo, hubo una especie de lucha entre USB y el protocolo Firewire, común principalmente en las computadoras Apple Macintosh.
GuerraFirewire-USB en reproductores portátiles: desdeiPod 1G – sóloFirewire - hastaiPod 5G – sóloUSB
Sin embargo, la mayor parte del audio portátil cambió rápida y fácilmente al bus serie universal, cerrando, al menos en el marco de las soluciones por cable, el problema de la transferencia de datos a nivel físico.
Las cosas no funcionaron tan simplemente con los protocolos de software. De esto corto periodo Cuando los fabricantes se vieron obligados a utilizar COM y LPT, los protocolos de software eran exclusivamente de diseño propio. De hecho, no podrían ser otra cosa, porque... Tanto las interfaces COM como LPT se crearon al mismo tiempo, por supuesto, no para transferir archivos multimedia a reproductores digitales portátiles. No había nadie para desarrollar controladores y shells de software para este último, excepto los propios desarrolladores, y no se habló en absoluto de estandarización.
Pero la llegada del USB no resolvió el problema. La industria se ocupa principalmente de la creación de protocolos estándar para dispositivos de almacenamiento móviles y cámaras digitales. La situación con los reproductores MP3 no estaba del todo clara: ¿estarían prohibidos o no? Y si no lo están, ¿qué características deberían tener los protocolos para que el foro SDMI dé el visto bueno? En tales condiciones, el desarrollo de protocolos de software todavía recaía sobre los hombros del desarrollador del dispositivo. Esto continuó durante al menos cuatro años, hasta que, finalmente, los protocolos estándar de transferencia de datos comenzaron a aparecer en los jugadores. Estos años fueron la época del predominio del primer tipo de protocolos de software: propietarios o cerrados.
Su rasgo característico eran los controladores y el software individuales para cada fabricante y, a menudo, para cada nueva generación de reproductores dentro de los productos del mismo fabricante.
Protocolo propietario como ejemplo.RCA-tomsonLira. Utiliza su propio controlador (PDP2222.SYS), que debe instalarse por separado en cada PC a la que planea conectar el reproductor
Esto crea muchos inconvenientes para el usuario. No se habla de transparencia: el propio usuario se ve obligado a instalar manualmente los controladores y el software para su reproductor. En este caso, pueden surgir varias dificultades, por ejemplo, si el comprador conecta por error el reproductor a la PC antes de instalar los controladores.
Al confundir el procedimiento para conectar el reproductor, el usuario se arriesgó a recibir un mensaje similar, incluso después de instalar todos los controladores necesarios.
También es mejor olvidarse de la compatibilidad: los controladores y el software solo funcionaban con un modelo de reproductor determinado (en el mejor de los casos, con varios modelos de un fabricante determinado), y el reproductor solo podía funcionar con una PC en la que estuvieran instalados estos controladores y software. Al principio, las capacidades de los shells de software eran muy escasas y se limitaban exclusivamente a copiar archivos de audio en la memoria del reproductor. Posteriormente, aparecieron varias formas de copiar contenido al reproductor: individualmente por pista o sincronizando el contenido de la memoria del reproductor con el contenido de una biblioteca compilada a partir de archivos de audio ubicados en una PC. Algunos shells de software admitían sólo uno de estos métodos. Con el tiempo, el software adquirió capacidades adicionales, por ejemplo, copiar cualquier archivo, no solo los soportados por el reproductor, lo que hizo posible usarlo como dispositivo de almacenamiento (la función recibió el sobrenombre de Data Taxi). Sin embargo, el hecho de que esta operación requiriera la instalación de controladores y software en la PC redujo seriamente la utilidad de esta función. Por regla general, no se hablaba en absoluto de las altas cualidades estéticas, el trabajo impecable y la buena ergonomía de las carcasas. Los usuarios de entonces eran, en su mayor parte, personas duras e intactas: copiaban archivos al reproductor, y eso está bien.
La mayoría de fabricantes pasaron por sistemas propietarios: iriver, Rio Audio, Creative, Cowon, Mpio, etc. Cada uno de estos fabricantes tuvo en algún momento sus propios controladores y su propio software, algunos más exitosos, otros menos exitosos. En cualquier caso, al cambiar el reproductor a un dispositivo de otro fabricante, el usuario se vio obligado a adaptarse al nuevo shell con su lógica y características. Muchos fabricantes siguen equipando sus dispositivos hoy en día con estos programas como alternativa a los estándares MSC/UMS o las soluciones MTP.
Propiedadcaparazón-gerentes: Iriver Music Manager, Cowon JetAudio, Mpio Manager, Creative Play Center
Un zoológico de todo tipo de conchas no podía satisfacer a los consumidores (todavía podían soportar la existencia de un grupo de conductores heterogéneos). Tampoco convenía a los fabricantes, especialmente a los pequeños que no tenían los recursos para desarrollar software de alta calidad. Por lo tanto, en 1999 y principios de la década de 2000, el uso de shells de terceros ganó cierta popularidad.
Entre ellos se encuentra el programa MusicMatch Jukebox.
InterfazMúsica Match Jukebox
Antes de la llegada de iTunes para PC con Windows, se utilizaba aquí para trabajar con el iPod de Apple. También trabajó con reproductores de otros fabricantes, como RCA-Thomson.
Programas como MusicMatch Jukebox fueron las primeras semillas de la estandarización. Permitieron utilizar reproductores de diferentes fabricantes sin instalar software adicional para cada uno de ellos. La solución no fue perfecta, fue solo un paso desde protocolos y shells variados hasta soluciones estandarizadas. En este caso, sólo se estandarizó la interfaz de control del protocolo; todavía era necesario instalar controladores separados para cada dispositivo. Los shells en sí no formaban parte del sistema operativo; debían instalarse por separado, desde Internet o desde el CD adjunto. Su funcionalidad, estabilidad y comodidad también plantearon a menudo dudas. No todos los reproductores eran compatibles, lo que obligó a los fabricantes a equipar sus dispositivos con complementos para administradores de programas populares.
Disponible para descargar en el sitio webRCA-Lyra: principalmente un complemento paraPartido de músicaJukebox y solo entonces tu propia conchaLiraDJ
Por lo general, con el tiempo, el programa "engordaba", se llenaba de funciones innecesarias para el usuario, publicidad y requería cada vez más recursos.
Otro caparazón popular en el pasado esRealJukebox
Al mismo tiempo, la presión competitiva iba en aumento: en 2001, Windows Media Player se convirtió en estándar en Windows XP y en 2003 apareció iTunes para Windows. Las pequeñas empresas asiáticas también encontraron en 2002-2003 un buen sustituto para este software: el protocolo abierto MSC/UMS. Como resultado, dispositivos como MusicMatch Jukebox han desaparecido de escena para dar paso a protocolos de próxima generación. Pero su legado no fue en vano: el modelo "un caparazón para diferentes jugadores" fue heredado en gran medida por el sistema Microsoft PlaysForSure.
Sin embargo, una característica de los sistemas propietarios les ha permitido sobrevivir más tiempo del razonable en ciertos mercados. Su carácter cerrado creaba obstáculos a la hora de utilizar el reproductor para transferir datos libremente de un PC a otro, es decir, según la RIAA, a la hora de utilizarlo como herramienta para la piratería digital. En mercados con problemas como el de Estados Unidos, las empresas que no estaban dispuestas a llamar demasiado la atención continuaron aplicando un enfoque patentado incluso después del auge de las soluciones genéricas.
en el sitio webEl firmware no propietario de iriver todavía se indica especialmente comoUMS oMTP
Aquí puedes recordar, por ejemplo, iriver o Creative. Los reproductores iriver generalmente se producían en dos versiones: para el mercado estadounidense, trabajando a través de un protocolo propietario, y para otros, a través de MSC/UMS abierto. Esta “vida después de la muerte” para los protocolos cerrados continuó hasta la aparición del protocolo MTP en 2004, que, siendo relativamente universal, también convenía a las compañías discográficas.
Período 2002-2004 Fue una transición de la “edad oscura” de los sistemas cerrados a la relativa apertura de los protocolos modernos. Hoy en día, los protocolos propietarios puros están completamente en desuso.
Probablemente hayas escuchado la frase "necesitas usar una VPN para proteger tu privacidad". Ahora estás pensando: "Está bien, pero ¿cómo funciona una VPN?"
Hay muchos artículos en Internet que sugieren utilizar un único protocolo, pero pocos se han tomado el tiempo de explicar algunas de las tecnologías VPN básicas. En este artículo te explicaré qué protocolos VPN existen, sus diferencias y qué debes buscar.
¿Qué es una VPN?
Antes de ver protocolos VPN específicos, recapitulemos rápidamente qué es una VPN.
Básicamente, una VPN le permite acceder a Internet pública mediante una conexión privada. Cuando hace clic en un enlace en Internet, su solicitud va al servidor correcto y generalmente devuelve el contenido correcto. Básicamente, sus datos fluyen sin problemas de A a B, y el sitio web o servicio puede ver su dirección IP, entre otros datos de identificación.
Cuando utiliza una VPN, todas sus solicitudes se enrutan primero a través de un servidor privado propiedad del proveedor de VPN. Su solicitud va de A a C pasando por B. Puede acceder a todos los datos previamente disponibles para usted (y en algunos casos, a más). Pero el sitio web o servicio sólo tiene los datos del proveedor de VPN: su dirección IP, etc.
Hay muchos usos para una VPN, incluida la protección de sus datos y su identidad, evitar la censura opresiva y cifrar sus comunicaciones.
¿Qué son los protocolos VPN?
El protocolo VPN determina exactamente cómo se enrutan sus datos entre su computadora y el servidor VPN. Los protocolos tienen diferentes especificaciones y ofrecen beneficios a los usuarios en diversas circunstancias. Por ejemplo, algunos priorizan la velocidad, mientras que otros se centran en la privacidad y la seguridad.
Veamos los protocolos VPN más comunes.
1. OpenVPN
OpenVPN es un protocolo VPN de código abierto. Esto significa que los usuarios pueden comprobar el código fuente en busca de vulnerabilidades o utilizarlo en otros proyectos. OpenVPN se ha convertido en uno de los protocolos VPN más importantes. OpenVPN es de código abierto y es uno de los protocolos más seguros. OpenVPN permite a los usuarios proteger sus datos utilizando un cifrado de clave AES-256 esencialmente irrompible (entre otros), con autenticación RSA de 2048 bits y SHA1 de 160 bits.
Además de proporcionar un cifrado sólido, OpenVPN también está disponible para casi todas las plataformas: Windows, MacOS, Linux, Android, iOS, enrutadores y más. Incluso Teléfono Windows¡Y Blackberry puede usarlo!
El protocolo OpenVPN ha sido criticado en el pasado debido a bajas velocidades. Sin embargo, las implementaciones recientes han visto cierta aceleración y el enfoque en la seguridad y la privacidad es digno de mención.
2.L2TP/IPSec
El protocolo de túnel de capa 2 es un protocolo VPN muy popular. L2TP es el sucesor del obsoleto PPTP (consulte la sección PPTP a continuación para obtener más detalles) desarrollado por Microsoft y L2F desarrollado por Cisco. Sin embargo, L2TP en realidad no proporciona cifrado ni privacidad.
En consecuencia, los servicios que utilizan L2TP suelen estar asociados con el protocolo de seguridad IPsec. Una vez implementado, L2TP/IPSec se convierte en una de las conexiones VPN más seguras. Utiliza cifrado AES de 256 bits y no tiene vulnerabilidades conocidas (aunque IPSec supuestamente fue comprometido por la NSA).
Sin embargo, si bien L2TP/IPSec no tiene vulnerabilidades conocidas, sí tiene algunas desventajas menores. Por ejemplo, de forma predeterminada, el protocolo utiliza UDP en el puerto 500. Esto facilita la detección y el bloqueo del tráfico.
3.SSTP
El protocolo Secure Socket Tunneling es otro protocolo VPN popular. SSTP tiene una ventaja notable: está completamente integrado con todos Sistema operativo Microsoft desde la instalación de Windows Vista SP1. Esto significa que puede utilizar SSTP con Winlogon o, para mayor seguridad, un chip inteligente. Además, muchos proveedores de VPN tienen instrucciones SSTP específicas integradas para Windows. Estos se pueden encontrar en el sitio web del proveedor de VPN.
SSTP utiliza certificados SSL/TLS de 2048 bits para la autenticación y claves SSL de 256 bits para el cifrado. En general, SSTP es bastante seguro.
SSTP es esencialmente un protocolo propietario de Microsoft. Esto significa que nadie puede inspeccionar completamente el código subyacente. Sin embargo, la mayoría de ellos todavía considera seguro el SSTP.
Finalmente, SSTP tiene soporte nativo para sistemas Windows, Linux y BSD. Android, macOS e iOS admiten clientes de terceros.
4. IKEv2
Internet Key Exchange versión 2 es otro protocolo VPN desarrollado por Microsoft y Cisco. IKEv2 en sí es un protocolo de túnel que proporciona una sesión de intercambio de claves segura. Por lo tanto (al igual que su predecesor), IKEv2 suele combinarse con IPSec para cifrado y autenticación.
Aunque IKEv2 no es tan popular como otros protocolos VPN, tiene muchas soluciones VPN móviles. Esto se debe a que es capaz de volver a conectarse en momentos de pérdida temporal de la conexión a Internet, así como durante un cambio de red (por ejemplo, de Wi-Fi a datos móviles).
IKEv2 es un protocolo propietario con soporte nativo para dispositivos Windows, iOS y Blackberry. Hay versiones de código abierto disponibles para Linux y la compatibilidad con Android está disponible a través de aplicaciones de terceros.
Desafortunadamente, si bien el protocolo ikev2 es excelente para comunicaciones móviles Hay pruebas contundentes de que la NSA de EE. UU. está explotando activamente sus fallos para socavar el tráfico IPSec.
5.PPTP
El protocolo de túnel punto a punto es uno de los protocolos VPN más antiguos. Todavía se utiliza en algunos lugares, pero la mayoría de los servicios hace tiempo que se actualizaron a protocolos más rápidos y seguros.
PPTP se introdujo en 1995. En realidad, estaba integrado con Windows 95, diseñado para funcionar con conexiones de acceso telefónico. Esto fue de gran ayuda en ese momento.
Pero la tecnología VPN ha progresado y PPTP ya no es seguro. Los gobiernos y los delincuentes han roto durante mucho tiempo el cifrado PPTP, lo que hace que los datos enviados mediante el protocolo no estén seguros.
Sin embargo, aún no está completamente muerto... Verá, algunas personas creen que PPTP ofrece mejores velocidades de conexión precisamente debido a la falta de funciones de seguridad (en comparación con los protocolos modernos). Por lo tanto, todavía se utiliza porque los usuarios simplemente quieren ver Netflix desde otra ubicación.
Resumamos los protocolos VPN
Hemos analizado cinco protocolos VPN principales. Resumamos rápidamente sus pros y sus contras.
AbiertoVPN: es de código abierto, ofrece el cifrado más potente adecuado para todas las actividades y tiene tiempos de conexión ligeramente más lentos.
L2TP/IPSec: Protocolo ampliamente utilizado, buenas velocidades, pero se bloquea fácilmente debido a la dependencia de un solo puerto.
SSTP: Buena seguridad, difícil de bloquear y detectar.
IKEv2: rápido, conveniente para dispositivos móviles, con varias implementaciones de código abierto (potencialmente socavadas por la NSA).
PPTP: rápido, ampliamente compatible pero lleno de agujeros de seguridad, solo se usa para transmisión y navegación web básica.
Para total seguridad y tranquilidad, elija un proveedor de VPN que le ofrezca una variedad de protocolos. Alternativamente, es posible que desee utilizar soluciones VPN pagas como ExpressVPN en lugar de un servicio gratuito. Cuando pagas por una VPN, estás comprando un servicio. Cuando usas una VPN gratuita, no tienes idea de lo que pueden hacer con tus datos.
¿Qué protocolo VPN sueles utilizar? ¿Su proveedor de VPN ofrece opciones? ¡Cuéntalo en los comentarios!
17 de julio de 2017 , Revista del BIS n° 3(26)/2017
Comparación de tecnologías y protocolos de acceso seguro
VPN es una parte integral de todos los sistemas de seguridad de la información, incluidos aquellos que protegen los sistemas de información de las organizaciones financieras. Esta tecnología es la forma más sencilla, comprensible y asequible de unir de forma segura sitios distribuidos geográficamente y proteger de forma fiable la información cuando se transmite a través de redes públicas.Hay muchos escenarios para usar VPN: organizar la interacción entre oficinas remotas, conectar empleados o clientes remotos, conectar cajeros automáticos, acceder a centros de datos en los que se concentran los recursos de los sistemas de información del banco. Además de la tarea de garantizar la interacción, en algunos casos, VPN permite crear un perímetro de protección claro y garantizar la disponibilidad de segmentos del sistema de información.
Sin embargo, antes de comenzar a elegir un proveedor de soluciones específico, es necesario e importante comprender qué tecnologías VPN existen y cuáles son las diferencias entre ellas.
PROTOCOLOS PROPIETARIOS
Todos los protocolos para la transmisión de datos se dividen en dos categorías.
La primera categoría que se discutirá son los protocolos y tecnologías patentados (cerrados) que son propiedad intelectual de empresas individuales. Las ventajas de este enfoque son que la tecnología se puede modificar con relativa rapidez para cumplir con los requisitos del fabricante del equipo o los deseos de un cliente específico. Sin embargo, también existen una serie de desventajas.
En primer lugar, existe una alta probabilidad de que el cliente se convierta en objeto de investigaciones y mejoras técnicas por su cuenta. Para reducir el riesgo de errores arquitectónicos, es necesario trabajar lo más completamente posible. nueva tecnología involucrando al mayor número posible de expertos. Desafortunadamente, la base de clientes de proveedores rusos que utilizan protocolos propietarios no siempre lo permite. Por cierto, los líderes extranjeros del mercado de TI no siguen el camino de la creación de protocolos propietarios. Desarrollan la funcionalidad de protocolos generalmente aceptados, abren el acceso a su tecnología y la hacen pública, a disposición de otros fabricantes.
En segundo lugar, una desventaja importante es que el diseño no estándar del producto y el comportamiento no documentado del dispositivo pueden hacer que el cliente dependa del proveedor del producto. Si la calidad del servicio o servicios ya no satisface al cliente, cambiar de un protocolo propietario a otro puede resultar extremadamente costoso, o incluso imposible, sin una revisión completa del sistema de seguridad. En el mejor de los casos, el cliente puede contar con el uso de plataformas de hardware usadas en las que se puede instalar software nuevo. Los especialistas de S-Terra CSP ya tenían experiencia en la instalación de su puerta de enlace VPN en las plataformas de Stonesoft (que, aunque utilizaba protocolos estándar, se sabe que ha cesado su actividad activa en el mercado de seguridad de redes en Rusia).
En tercer lugar, cualquier diseño no estándar crea problemas a la hora de solucionar problemas o fallos de funcionamiento de los dispositivos. Es necesario contar en plantilla con personas que conozcan el comportamiento tanto de los equipos estándar como del funcionamiento específico de las tecnologías de un fabricante en particular.
Y en cuarto lugar, hay que tener en cuenta el hecho de que un protocolo propietario tiene posibilidades mínimas de lograr compatibilidad con otros fabricantes.
PROTOCOLOS PÚBLICOS
La segunda categoría son los protocolos públicos (o estándar), que se pueden utilizar en equipos fabricados por varios proveedores. Se proporciona una descripción de estas tecnologías en documentos especiales (Solicitud de comentarios, RFC) del Internet Engineering Task Force (IETF). Son creados y complementados por los mejores expertos de la industria. Para VPN, los protocolos públicos más utilizados son IPsec y SSL en diversas variaciones.
SSL (TLS)
Esta familia de protocolos está diseñada para proporcionar acceso remoto a clientes y se centra en aplicaciones específicas. aplicaciones personalizadas. Hay varias opciones para usar SSL (TLS):
Modo sin cliente. Este modo utiliza autenticación unidireccional desde el servidor al lado del cliente. En este caso, el usuario no necesita instalar un software cliente especializado para proteger el tráfico; basta con tener un proveedor de cifrado en la estación de trabajo. Trabajar en este modo solo es posible con aplicaciones web y, en la realidad rusa, existe una conexión al no muy popular navegador Internet Explorer. Este modo de funcionamiento es adecuado, por ejemplo, para una lista limitada de escenarios para el acceso seguro a un portal web.
Modo cliente. Si necesita proporcionar acceso a cualquier otra aplicación, se utiliza un cliente SSL (TLS) especial. En este modo, es posible utilizar la autenticación bidireccional.
Una de las principales ventajas del protocolo es la ausencia o la mínima necesidad de configuración personal del cliente. Sin embargo, si se instala nuevo software en la estación de trabajo o nuevo servicio, que requiere acceso, el usuario deberá agregar estos parámetros a la configuración del cliente.
También debe tener en cuenta el hecho de que SSL estándar opera a nivel de aplicación y no puede proteger el tráfico de equipos o segmentos de red. El protocolo DTLS puede solucionar este problema, pero también tiene un modelo cliente-servidor y no es muy utilizado entre los fabricantes rusos.
IPsec opera en una capa inferior del modelo OSI y no requiere soporte de aplicaciones para funcionar. Es perfecto para crear conexiones seguras tanto entre sucursales en una red distribuida geográficamente como para organizar un acceso remoto seguro.
Debido al protocolo que funciona a nivel de red, el funcionamiento de VPN no requiere cambios en el software en el lugar de trabajo. Todas las aplicaciones de usuario funcionan de forma “transparente” y no conocen la existencia de la VPN. El protocolo siempre proporciona autenticación bidireccional.
Al implementar el acceso remoto, se requiere una configuración de cliente personalizada para cada estación de trabajo específica. Al mismo tiempo, el cliente protege todas las interacciones de red entre la estación de trabajo y la red remota. En consecuencia, la necesidad de contar con medios de protección contra el acceso no autorizado a las estaciones de trabajo en los lugares de trabajo de los usuarios es más urgente que en el caso de SSL.
IPsec es el protocolo más conocido para crear VPN y continúa evolucionando. Ha aparecido la segunda versión del protocolo de distribución de claves IKE; la pila de protocolos es parte del estándar IPv6.
Además de lo anterior, los protocolos estándar IPsec y SSL (TLS) tienen ciertas ventajas en la realidad rusa. Estamos hablando de las actividades del comité técnico para la estandarización "Protección de la información criptográfica" (TC 26) en el campo del desarrollo de recomendaciones para el uso de nodos de reemplazo uniformes y parámetros de curva elíptica en los GOST rusos para criptografía, así como su uso en protocolos de transferencia de datos. Esta actividad ya ha dado sus frutos: varios fabricantes rusos, incluida la empresa S-Terra SSP, han garantizado la compatibilidad de sus soluciones certificadas cuando utilizan el protocolo IPsec. Por supuesto, si se hubieran utilizado protocolos propietarios, tales resultados no se habrían logrado. Aunque estos procesos no ocurren rápidamente, los clientes tienen la posibilidad de hacer realidad su sueño más preciado: la aparición de compatibilidad técnica de varias soluciones VPN certificadas entre sí.
El uso de protocolos estándar en diferentes áreas (Syslog, SNMP, Netflow, etc.) permite combinar productos en un solo sistema. Por ejemplo, esta práctica se acepta generalmente cuando se resuelven problemas de monitoreo y construcción de sistemas SIEM.
SACAMOS CONCLUSIONES
Al elegir un protocolo estándar, el cliente debe determinar el caso de uso deseado. Si le basta con proteger solo los servicios individuales y es importante la facilidad de configuración (SSL (TLS), si es necesaria una conectividad de red completa entre objetos), su elección es IPSec.
Al mismo tiempo, hay que recordar que además del protocolo de transferencia de datos, cada solución cuenta con una gran cantidad de diferentes tecnologías y características. Por lo tanto, vale la pena evaluar y comparar los productos en su conjunto, dependiendo de la tarea en cuestión.
Hoy hablaré sobre un maravilloso protocolo de transmisión. RTMFP. Implementa muchos enfoques interesantes y existen muchos prejuicios sobre sus capacidades. Quiero despertar el interés por este tema y disipar las ilusiones existentes. No encontré nada mejor para retransmitir en directo, así que decidí escribir este post.Fondo
Hace mucho tiempo en una galaxia muy lejana...En 2004 vivió Amicima, Inc. en el que se desarrolló la implementación del protocolo GPL multifunción - MFPNet. Luego lo liberaron amiciPhone- uno de los competidores de Skype, pero debido a problemas de posicionamiento las cosas no salieron muy bien. En 2007, Adobe los adquirió porque necesitaban un buen protocolo de transmisión en tiempo real.
¿Qué pasa con RTMP?
RTMP no es un protocolo de transmisión en tiempo real:- el problema de minimizar los retrasos no está resuelto;
- la transmisión se detiene cuando se cambia la dirección del dispositivo;
- TCP aumenta significativamente la latencia y sobrecarga los mensajes con comprobaciones de entrega innecesarias;
- sin control del tamaño de la ventana.
Ideas preconcebidas sobre RTMFP
Este es un protocolo propietario.
Adobe decidió publicarlo en el formato RFC7016 para llamar la atención del público, pero de alguna manera funcionó. Curiosamente, esto no parece una especificación RTMP torcida y se parece más a una impresora multifunción.El protocolo en sí es modular: el intercambio de certificados, el cifrado y la sincronización de transmisiones se implementan como un perfil separado. Lo que sucede en Flash permanece en Flash. Para desarrolladores de soluciones de terceros, como Cúmulo Flash siguió siendo una caja negra; De alguna manera silenciosa e imperceptiblemente salió a la luz en abril de 2014. Perfil RTMFP de Adobe para comunicación Flash.
Esto es UDP, lo que significa que no hay garantía de entrega.
Muchos protocolos en tiempo real utilizan UDP y agregan una suma de verificación de red y comprobaciones de entrega selectivas para garantizar la entrega. Sólo comprueban lo que debe llegar, y no todo seguido. Para audio/vídeo, controlar la entrega de paquetes no tiene mucho más sentido. El tamaño de la ventana (MTU) suele ser máximo y estático, lo que aumenta la probabilidad de que se produzca una situación de reproducción vacía con la posterior recepción de datos irrelevantes cuando se pierde un paquete.No necesitamos RTMFP, tenemos WebRTC
WebRTC Esto no es un protocolo, es una tecnología de navegador: un intento de integrar SIP con una pila RTP en un navegador. Si combinas RTP, SRTP, SCTP, RTCP, ZRTP, RTSP, obtienes RTMFP. Pero en varios casos, dichas conexiones tienen redundancia y problemas de direccionamiento que no están presentes en RTMFP.RTMFP tiene reenvío a través de NAT, control de tamaño de ventana, metadatos para flujos con control de redundancia en el lado de la aplicación, reenvío/redireccionamiento de sesiones y su propio DHT.
¿Cuántos protocolos similares a RTP necesitas encapsular para implementar todo esto? Pienso en 4 o 5 piezas.
La implementación actual de protocolos de transmisión se parece a la situación:
"Hay 6 protocolos, pero todos tienen un defecto fatal, y desarrollaremos otro..."
Pasa un año.
"Hay 7 protocolos y todos tienen un defecto fatal..."
RTMFP no es un intento de reemplazar las soluciones existentes. Se trata de un intento de generalizarlos, eliminar la redundancia y hacerlos accesibles a los usuarios.
Modelo RTMFP y OSI
Entonces, veamos qué capas del modelo OSI cubre el protocolo RTMFP.Físico y canal
No hay fluctuaciones efímeras de energía por el revoloteo de las mariposas, pero nos gustaría la redundancia mediante la transferencia de datos en subespacios warp.Red y transporte
Estos son multidifusión IP y UDP.
Hay descubrimiento de MTU de ruta y control de congestión, ya en el cuadro, para cada flujo específico. Existe un modo de transmisión de datos con una frecuencia de verificación de entrega selectiva: lo verificamos una vez cada N paquetes. Todos los paquetes tienen una marca de tiempo para medir el retraso en la entrega. Direccionamiento hash de anillo integrado para puntos finales DHT.Capa de presentación
Para Flash, esto es, por supuesto, AMF3 y RTMP encapsulado, pero se puede transmitir cualquier otro dato.
Seguridad en RTMFP
- Intercambio de claves clásico Diffie-Hellman con claves estáticas y efímeras.
- Cookies y certificados en sesiones, con capacidad de firmar digitalmente paquetes. Es cierto que, de forma predeterminada, los paquetes sin firmar se consideran válidos.
- AES128 se utiliza para el cifrado, pero se puede utilizar cualquier otro algoritmo de bloque.
- HMAC-SHA256 o sumas de comprobación de red.
¿Dónde está la característica principal?
Creo que todos recuerdan el fracaso de la retransmisión de la última presentación del nuevo teléfono pop IPhone 6 Plus.Imaginemos que un cliente recibe una transmisión entrante y la transmite a dos o más (si es posible), y así sucesivamente, siempre que lo permita el máximo retraso posible. Al mismo tiempo, se producen permutaciones y clasificaciones en el árbol de clientes en tiempo real para minimizar retrasos y optimizar la ventana del paquete. Como resultado, puede lograr una reducción múltiple en el tráfico saliente del servidor de transmisión.
Y todos lo verán...
Casos de uso
Transmitir contenidos en tiempo real
En realidad, este es el propósito del protocolo en sí y cumple muy bien con esta tarea.
Puede utilizarse no sólo para la transmisión de audio/vídeo, sino también como transporte principal en juegos Flash.CDN
Esto es P2P y para descargar un archivo sólo necesitas saber su nombre, hash y tamaño.
Puede implementar una puerta de enlace http2rtmfp; las posibilidades son bastante interesantes.Videoconferencias y chats
En la era post-Snowden, RTMFP es un transporte P2P accesible y seguro. Además, la principal ventaja es la posibilidad de continuar transmitiendo cuando se cambia la dirección de red del dispositivo. WebRTC puede caerse al cambiar de celda en 3G/4G. La pila RTP no es adecuada para transmitir en dicho entorno.Transferencia de datos en tiempo real dentro de redes privadas
La principal ventaja de este caso de uso es la posibilidad de políticas de enrutamiento flexibles, minimización de retrasos, verificación de entrega de paquetes opcional y herramientas integradas de priorización del tráfico. Todo esto se puede configurar individualmente para cada aplicación específica.
¿Cuál es el problema con las soluciones RTMFP existentes?
En resumen, las cosas están muy mal. Hoy en día, la única implementación abierta es Cumulus. Se desarrolla muy lentamente. No se basa en el RFC, sino en el primer RTMFP Cirrus 1 inverso, por lo que la compatibilidad con el actual Flash Profile Cirrus 2 es bastante cuestionable. Implementa la mayoría de las utilidades, incluida la organización de la redundancia en P2P y la transmisión entre dispositivos. Hay FMS, pero funciona como FMS...Estaré encantado de recibir comentarios constructivos.
En los comentarios, indique los análogos de RTMFP si los conoce.
