Re: Erm...
> If you even remotely care about security, you’ll need to check the client certificate at the firewall
You can't do that unless your firewall is performing a man-in-the-middle attack on the session - that is, spoofing a false server certificate back to the client, which the client is configured to trust.
Both are sort of right. You can check both client and server certificates at the firewall, because at that point, the communication is still being made in cleartext. Certificate exchanges are sent as part of the initial handshake. Firewalls are capable of MITMing stuff... however, parsing an X.509 certificate and validating it is going to be resource intensive. It's less the job of a regular firewall and more of an IDS/IPS thing, and even then it's going to be so resource intensive that it'll slow down all outgoing traffic. Why? Because you'll need to check all outgoing traffic, see if it's an SSL/TLS handshake, then check the handshake itself, parse the X.509 certs, validate them .... you get the idea.
This is going to suck, because the only way I see this being mitigated is by forcing all traffic to go through proxies, then having those proxies offload all CONNECT requests to an IPS. There's a lot of software out there that shits itself whenever you try to make it go through a proxy...