Su pregunta es un poco confusa (indica que "la conexión entre el proxy y la aplicación está cifrada mediante SSL" y luego que "la conexión entre la aplicación y el proxy NO está cifrada": al parecer, está utilizando el término " aplicación "para designar varias cosas distintas).
Dicho esto:
-
SSL está destinado a ser de extremo a extremo. Cuando el cliente SSL habla con el servidor SSL, establece un túnel que está a salvo de terceros (para la confidencialidad y la integridad de los datos). Esta propiedad es válida incluso contra cualquier proxy por el que se haya conectado la conexión.
-
HTTPS (es decir, HTTP dentro de SSL) se puede reenviar a través de un proxy (consulte RFC 2817 secciones 5.2 y 5.3).
-
Se establece contacto con un proxy HTTP a través de HTTP: en teoría, debería ser posible contactarlo también a través de HTTPS, pero los navegadores no son necesariamente configurables de esa manera. Lo he visto hecho con un archivo de configuración automática de proxy que devolvía el proxy no como un par de nombre de host y puerto , pero como una URL completa (comenzando con https
), que está fuera de especificación, pero estaba funcionando (aunque no recuerdo qué navegador era compatible con eso).
Por lo tanto, podría hacer una conexión SSL a través de un proxy, el túnel entre la aplicación y el proxy es un túnel SSL; en ese punto tendría dos túneles SSL, uno anidado en el otro. ¿Pero cuál sería el uso? Si los datos son lo suficientemente confidenciales para garantizar SSL, entonces debe usar SSL en toda la ruta, incluso más allá del proxy. Y si hace utiliza SSL para toda la ruta, entonces una capa SSL entre la aplicación y el proxy es superflua.
(HTTPS con proxy tiene sentido cuando el proxy requiere autenticación basada en contraseña y, sin embargo, teme que se intercepte esa contraseña)