On 6/8/20 11:12 AM, Nick Hilliard wrote:
ssl, then later tls, took hold because it was designed for, and
therefore easily applied to tcp sessions and because there was a lot
of effort put into creating ancillary frameworks, e.g. the pki,
sensible APIs, etc. This push towards application usability made it
transparent to the protocol consumer, whether that be granny, or 14yo
whizz-kid, or someone trying to do some online shopping.
Obviously you're technically correct that an app can call any library
function and that it matters little to a CPU or the data, or the
network layer whether it's rsa, aes or sha - or ipsec, or tls or
whatever. But the success of tls came down to usability, or more
specifically use-transparency: security could be implemented without
people even being aware of it and shifting people from unencrypted to
encrypted data transfer was a easy as configuring a server-side
redirect. Conversely configuring and managing ipsec still creates
thundering headaches even for experienced operators.
ssl had the advantage that it 1) beat ipsec to market, and 2) wasn't
subject to API differences from OS layer calls like IPsec was, and with
quite a bit of churn as i recall too. it's really too bad, imo. we
wouldn't have had to do the contortions of dtls, for example. and now
there's this problem. none of them are earth shattering, but it would
have been cleaner.
Mike
