1. That feature is a feature of the OpenSSL implementation, not a feature of TLS itself.
2. It's also incredibly useful for debugging SSL implementations. (Much more so than as some sort of backdoor, since that's what you seem to be implying.)
I don't know of an environment variable to enable that with OpenSSL, but there is one for NSS. For recent versions it has to be enabled at compile time, but it's enabled for the official Firefox binaries.
Without that, you can't intercept https traffic and analyse it properly with tools like charles or wireshark. They both rely on reading the keyfile openssl et al write out when triggered to do so.
Looking forward to TLS 1.3. Starting testing Nginx 1.11.13 + OpenSSL 1.1.0 draft 18 branch with TLS 1.3 myself https://community.centminmod.com/posts/47692/ not quite there yet. Needs some love on Nginx end too :)
Only server identity. Our situation in our project is that the TLS server side already has an OpenPGP key for other purposes anyway, so it is very practical to use it as an identity check inherent in the TLS handshake.
On the topic of X.509 certificates, I can only point to Peter Gutmann: Everything you Never Wanted to Know about PKI but were Forced to Find Out (https://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf) Basically, X.509 certificates are very complex, and many security bugs have historically been found in the parsing code for them.
Current popular implementations of it. There is nothing technical in IPSec per se stopping it from being implemented as a library, userspace server, or anything like that.
In reverse, IPSec is typically usable in arbitrary protocols and applications without special support for it, unlike TLS.
https://media.ccc.de/v/33c3-8348-deploying_tls_1_3_the_great...