3 ms·

I can confirm. In my work deploying desktop software to institutions, often academic and medical, I had to disable client-side certs to allow for connections t

I can confirm. In my work deploying desktop software to institutions, often academic and medical, I had to disable client-side certs to allow for connections to be made. Apparently, even though it should be technically more secure, client-side certs are so infrequently used, these types of gateway monitors block connections made with them! Maybe not as surprising, but non-browser software making connections to servers with non-publicly-signed SSL certs (but embedded CA chains) were also blocked.

TechnicalVault 10y ago
This makes me sad. Academic and medical sites should really be the last places using TLS breaking gateways. Mainly because staff frequently have to sign legal confidentiality and data access agreements granting them personal access to other institutions patient data rather than having an institutional agreement. Posture checking and zero internal network trust really needs to take hold in these places. If people must tap TLS, they should do it via installation of software client side, not MITM.
gsylvie 10y ago
Thanks for confirming! If the client certs are provisioned correctly (and validated correctly on the server side), then they fundamentally should break corporate TLS/SSL gateways. For example, I would store the username in the client cert's EMAIL field when provisioning it, and then check on the server that the same user is authenticating, binding the client cert to a single user. The TLS/SSL gateway is then going to need to have each user's client cert on hand (with private key) if it wants to intercept the traffic. The only way around I think would be if the TLS/SSL gateway (such as Forcepoint) gave the user a way to upload their client cert with its private key directly into the TLS/SSL gateway... hmm, I wonder if they already allow this. p.s. I call these gateways "lan-in-the-middle" attacks.

TechnicalVault 10y ago

This makes me sad. Academic and medical sites should really be the last places using TLS breaking gateways. Mainly because staff frequently have to sign legal confidentiality and data access agreements granting them personal access to other institutions patient data rather than having an institutional agreement. Posture checking and zero internal network trust really needs to take hold in these places. If people must tap TLS, they should do it via installation of software client side, not MITM.

gsylvie 10y ago

Thanks for confirming! If the client certs are provisioned correctly (and validated correctly on the server side), then they fundamentally should break corporate TLS/SSL gateways. For example, I would store the username in the client cert's EMAIL field when provisioning it, and then check on the server that the same user is authenticating, binding the client cert to a single user. The TLS/SSL gateway is then going to need to have each user's client cert on hand (with private key) if it wants to intercept the traffic. The only way around I think would be if the TLS/SSL gateway (such as Forcepoint) gave the user a way to upload their client cert with its private key directly into the TLS/SSL gateway... hmm, I wonder if they already allow this. p.s. I call these gateways "lan-in-the-middle" attacks.