Cómo implementar mi propio mecanismo de seguridad: evitar SSL

Estoy considerando la implementación de mi propio mecanismo de seguridad en lugar de usar SSL debido a que SSL es 'desesperadamente roto ' y también porque es un ejercicio interesante :)
Esto es para una aplicación de internet cliente-servidor.

Advertencia: no soy un experto en seguridad, solo he estado leyendo sobre seguridad.
También construiré la aplicación cliente, por lo tanto tendré control sobre la implementación de ambos lados.

Problema SSL

El principal problema que veo con SSL se debe al intercambio de claves públicas en la etapa de apretón de manos, y un hombre en el medio que lo intercepta. SSL intenta evitar este problema mediante la firma de mensajes y certificados, etc. para validar la clave pública del servidor al cliente. Pero un atacante con un certificado falsificado todavía puede sortear esto.

Solución

Debido a este problema de intercambio seguro de claves públicas, creo que esto se puede evitar simplemente no teniendo que intercambiar la clave pública del servidor, al tener una clave pública del servidor "conocida" incorporada en cada aplicación cliente. Diga una clave RSA de 3072 bits.

Implementación

1. La implementación para cada sesión de comunicación sería por lo tanto el cliente genera un par de claves RSA públicas / privadas
2. el cliente cifra su nueva clave pública con la clave pública del servidor y la envía al servidor
3. el servidor descifra el mensaje para descubrir la clave pública del cliente y luego lo usa para cifrar cualquier respuesta al cliente
4. el cliente continúa enviando tráfico al servidor cifrado con la clave pública del servidor
5. cada mensaje enviado desde el cliente también contiene en el encabezado:
   1. el nombre de usuario del cliente cifrado con la clave pública del servidor
   2. un hash del mensaje del cliente sin cifrar: se utiliza como entrada para generar este hash, otro hash de [nombre de usuario del cliente + dominio + contraseña del cliente]

Observaciones

• El servidor puede probar la identidad del cliente descifrando primero el mensaje usando su clave privada, y luego calculando el hash del mensaje no cifrado usando el hash de [nombre de usuario del cliente + contraseña real] que ha almacenado en su base de datos.
• El hombre en el medio no puede monitorear el tráfico ya que está cifrado en ambos sentidos
• El hombre en el medio no puede hacerse pasar por cliente porque no puede generar un hash de mensaje válido
• El hombre en el medio no puede hacerse pasar por un servidor porque, como no puede descifrar el mensaje inicial, no puede descubrir la clave pública del cliente para cifrar las respuestas al cliente
• La propia contraseña del cliente está protegida contra el escrutinio de fuerza bruta, ya que el hash que usó la contraseña del cliente como entrada, está contra el mensaje no cifrado, por lo que el atacante primero tendría que descifrar el mensaje antes de comenzar un ataque de fuerza bruta contra este hash

Viendo que no soy un experto en seguridad, espero que alguien que sepa más sobre seguridad pueda detectar cualquier agujero en este enfoque, o confirmar si es bueno. Y también si una clave RSA de 3072 bits puede soportar la prueba del tiempo sin romperse.

¡Gracias!