¿Mi empleador está descifrando el tráfico "seguro"?

1

Recientemente, cuando comenzamos a contribuir a un proyecto alojado en GitHub, observamos que hay problemas con la conexión segura:

$ ssh -T [email protected]
Connection closed by 192.30.253.112 port 22

Tuvimos que repetir el intento de conexión varias veces al comienzo de cada día, y luego funcionó por el resto del día. Nos contactamos con el departamento de TI y dijeron algo así: "OK, agregaremos el filtro para no descifrar las claves ssh para GitHub". Desde entonces, GitHub está funcionando bien, pero tengo miedo de usar la computadora dentro de la red de la empresa incluso para abrir mi correo electrónico.

Otro ejemplo relacionado con ssh:

$ ssh -v  ******@*****.home.pl
OpenSSH_7.6p1 Ubuntu-4, OpenSSL 1.0.2n  7 Dec 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to *****.home.pl [***.***.220.52] port 22.
debug1: Connection established.
debug1: identity file /home/goto/.ssh/id_rsa type 0
debug1: key_load_public: No such file or directory
debug1: identity file /home/goto/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/goto/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/goto/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/goto/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/goto/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/goto/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/goto/.ssh/id_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4
debug1: Remote protocol version 2.0, remote software version HomeSSH-v1.2
debug1: no match: HomeSSH-v1.2
debug1: Authenticating to *****.home.pl:22 as '*****'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: ecdh-sha2-nistp256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:iiQ18jC************dyxJJ4FhOWK/1o
The authenticity of host '*****.home.pl (***.***.220.52)' can't be established.
ECDSA key fingerprint is SHA256:iiQ18jC*********dyxJJ4FhOWK/1o.

Hoy quise usar NordVPN para poder usar de forma segura mi correo electrónico privado, pero incluso allí tengo un problema de conexión:

$ sudo openvpn /etc/openvpn/ovpn_tcp/us327.nordvpn.com.tcp.ovpn 
Mon Jul  9 13:26:42 2018 OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 10 2018
Mon Jul  9 13:26:42 2018 library versions: OpenSSL 1.1.0g  2 Nov 2017, LZO 2.08
Enter Auth Username: **********
Enter Auth Password: **********
Mon Jul  9 13:26:55 2018 WARNING: --ping should normally be used with --ping-restart or --ping-exit
Mon Jul  9 13:26:55 2018 NOTE: --fast-io is disabled since we are not using UDP
Mon Jul  9 13:26:55 2018 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Jul  9 13:26:55 2018 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Jul  9 13:26:55 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]104.145.235.35:443
Mon Jul  9 13:26:55 2018 Socket Buffers: R=[87380->87380] S=[16384->16384]
Mon Jul  9 13:26:55 2018 Attempting to establish TCP connection with [AF_INET]104.145.235.35:443 [nonblock]
Mon Jul  9 13:26:56 2018 TCP connection established with [AF_INET]104.145.235.35:443
Mon Jul  9 13:26:56 2018 TCP_CLIENT link local: (not bound)
Mon Jul  9 13:26:56 2018 TCP_CLIENT link remote: [AF_INET]104.145.235.35:443
Mon Jul  9 13:27:56 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Jul  9 13:27:56 2018 TLS Error: TLS handshake failed
Mon Jul  9 13:27:56 2018 Fatal TLS error (check_tls_errors_co), restarting
Mon Jul  9 13:27:56 2018 SIGUSR1[soft,tls-error] received, process restarting
Mon Jul  9 13:27:56 2018 Restart pause, 5 second(s)
Mon Jul  9 13:28:01 2018 WARNING: --ping should normally be used with --ping-restart or --ping-exit
Mon Jul  9 13:28:01 2018 NOTE: --fast-io is disabled since we are not using UDP
Mon Jul  9 13:28:01 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]104.145.235.35:443
Mon Jul  9 13:28:01 2018 Socket Buffers: R=[87380->87380] S=[16384->16384]

Estoy seguro de que está relacionado con algunas políticas y configuraciones de la compañía en el firewall. La pregunta es qué hace el departamento de TI y cuáles son las amenazas de seguridad relacionadas con eso. ¿Está expuesto mi tráfico web SSL? ¿Qué puedo hacer para usar el acceso seguro a Internet (o cómo conecto NordVPN)?

    
pregunta gozwei 09.07.2018 - 13:50
fuente

1 respuesta

3

Ninguno de sus ejemplos muestra si están o no interceptando el tráfico, aparte de su declaración sobre github. La única manera de estar seguro es intentar establecer una conexión y verificar si la clave pública que recibe es la legítima para esa conexión. (Obtenido de forma segura.)

La mayoría de las compañías tienen una política que le prohíbe intentar eludir sus controles de seguridad. No sugeriría que intente conectarse a un servicio como NordVPN en el equipo de su empresa.

    
respondido por el David 09.07.2018 - 21:43
fuente

Lea otras preguntas en las etiquetas