¿Los protocolos personalizados son inseguros?

Sospecho que ya respondiste tu propia pregunta.

El mero hecho de que quiera proteger los datos implica que es confidencial y no debe modificarse ni filtrarse. Si este no es el caso, ¿por qué molestarse en protegerse?

Si lo contrario es cierto (los datos deberían estar protegidos), entonces la "regla" indica que el uso de protocolos personalizados y algoritmos de cifrado no es recomendable.

Edit: Dada su aclaración: aunque sea leve, siempre existe la posibilidad de introducir vulnerabilidades en el servidor / cliente cuando se usan protocolos personalizados (el grado de posibilidad obviamente dependerá completamente de lo que haga y de cómo lo haga) . Dado que ahora hemos determinado que la lista de la compra no tiene ningún valor, los datos parecen inútiles tratar de protegerlos de una manera que potencialmente podría abrir vectores de ataque adicionales en el cliente / servidor.

No tendría sentido tratar de proteger algo "sin valor", incluso con la mínima posibilidad de que el mecanismo de protección pueda exponer algo valioso.

Al final, se trata de su apetito por el riesgo y de lo que considera más riesgoso. ¿Se están filtrando los datos de la lista de la compra o se están creando más vulnerabilidades?

Esto es asumiendo que puedes ir sin los protocolos personalizados.

Por definición, si no importa si alguien tiene acceso o modifica sus datos, entonces no es confidencial y no tiene que ser seguro. Para las cosas que tienen que ser seguras, no se recomienda utilizar un protocolo personalizado a menos que pueda invertir la enorme cantidad de tiempo y recursos necesarios para garantizar su seguridad (millones).

Tenga en cuenta que también hay una diferencia entre los protocolos de seguridad y de datos. Podría usar algo como SSL y usar cualquier protocolo que desee para intercambiar los datos. De manera similar, podría tener su propio sistema para verificar las credenciales del usuario, pero los algoritmos hash y los algoritmos de cifrado y cualquier otra cosa que pueda usar estándares deberían hacerlo.

Hay mucha más flexibilidad en la forma en que usan los estándares juntos que en tratar de hacer su propio estándar. Ciertamente, es preferible utilizar un sistema estándar completo si es posible, pero es mucho menos oneroso probar la seguridad cuando está utilizando componentes que pueden asumir que hacen su trabajo de manera segura y bien entendida.

Debe hacer una distinción entre el protocolo aplicativo y el protocolo de transporte . SSL / TLS es un protocolo de transporte: garantiza algunas garantías relacionadas con la seguridad (confidencialidad, integridad, alguna autenticación) para un flujo de bytes bidireccional. Lo que estos bytes significan es lo que define el "protocolo aplicativo". P.ej. en HTTPS, HTTP es el protocolo aplicativo y SSL es el protocolo de transporte.

Definir tu propio protocolo aplicativo es completamente tuyo. Puede dañar su propia implementación y tener, por ejemplo, desbordamientos de búfer; pero, de lo contrario, no hay nada en la definición de protocolo aplicativo que ponga en peligro las garantías de seguridad ofrecidas por el protocolo de transporte: desde el punto de vista de SSL, los bytes son bytes. Sin embargo, hay una pequeña advertencia: SSL garantiza la confidencialidad para los bytes valores , pero la longitud de las fugas de datos cifrados. La fuga de longitud de datos ha sido una fuente de problemas, por ejemplo, el llamado CRIME attack .

Definir tu propio protocolo de transporte es una mala idea . O bien los datos aplicativos no necesitan ninguna de las propiedades de seguridad de SSL como protocolo de transporte, en cuyo caso el método más simple y eficiente es no usar SSL en absoluto, solo TCP en bruto; O todavía necesita algo de seguridad, y "hacer rodar la suya" es una receta conocida para el desastre. El tono subyacente es que, contrariamente a una creencia generalizada, hay poco espacio para la optimización adicional en SSL: hay muy pocas partes del protocolo que pueden eliminarse sin romper por completo la seguridad.

(Lo que puede hacer, sin embargo, es reducir las funcionalidades: admite solo un conjunto de cifrado en el cliente y el servidor, eliminar las extensiones innecesarias, etc.). Esto sigue siendo un estándar SSL / TLS, y todavía usa las bibliotecas SSL / TLS existentes, que es el punto.)

Creo que estás preguntando si un pirata informático podría causar problemas a tus servidores domésticos si estás utilizando un protocolo inseguro para datos. Esto depende completamente de cómo maneje los datos y cómo implemente el análisis de los paquetes de información.

Si SOLO está utilizando el protocolo personalizado para datos no confidenciales e implementando buenas prácticas de seguridad (como bloquear solicitudes demasiado largas y truncar correctamente cadenas terminadas en nulo, cerrar y temporizar conexiones, etc.), entonces podría estar enviando los datos en el formato que desee.

También puedes preguntarte qué tan probable es la amenaza de un ataque. Dependiendo de su ubicación y situación, puede ser seguro asumir que no necesita preocuparse demasiado. Pero personalmente no me gustaría arriesgarme así si no tuviera que hacerlo.

Desde el punto de vista de la ingeniería, probablemente te ahorrarías un tiempo utilizando un protocolo estándar y bibliotecas decentes, pero si quieres hacer lo tuyo, diviértete con él.