walt posted on Thu, 03 May 2012 06:32:09 -0700 as excerpted: > On 05/02/2012 06:04 PM, Duncan wrote: > > <interesting crypto gossip snipped> > >> if the site uses self-signed certs and you accept the valid one, if it >> changes, at least to another self-signed, you'll normally get the usual >> warnings all over again, and can act accordingly. > > Very good point. So pan ideally should check for consistency at least > when starting a new session, and complain only if the cert changes > between sessions. > > Hm. I've never thought about it before, but any ssl client may routinely > open hundreds or even thousands of connections during a single session, > right? Does the client then trot off to verify the server cert for > every one of those thousands of connections? That's a lot of bandwidth > used.
Well, SSL=secure-socket-layer. By definition, each connection must use a different socket (socket being the combination of IP address and TCP port, with a connection actually being identified by two sockets, one at each end). And each secure connection not only has the TCP negotiation to handle, but also the encryption negotiation, keeping in mind that the initial negotiation is done using asymmetric encryption, in effect using the (self or certificate chain signed) public key of the server in question, which then decrypts using the private key. But during the initial phase the two ends negotiate a shared-secret symmetric encryption key of whatever strength, which is then used by both sides to encrypt/decrypt the ongoing session. Actually, strictly by the original standard, either side can force renegotiation after the initial negotiation is completed, too, but in practice that basically didn't happen, some implementations didn't actually do that bit, and fairly recently it turned out they were correct not to, as the forced renegotiation turned out to severely weaken the security and allow successful MitM attacks. Meanwhile, do keep in mind that despite the verification of the signing chain, it's only the server's own certificate that gets sent. It's actually verified against a local certificate authority store, both to keep the bandwidth/latency manageable and to prevent the signers from being able to track traffic via the checks. Depending on the implementation, a remote certificate revocation list may be checked, but that's normally kept locally and updated periodically as well, again, to keep the holder of the revocation list from being able to track who's asking about revocations for what sites. But, connections can be reused. Thousands of connections during a single session? Not normally, because the existing connections are reused for more than one transaction. This is even more important for secure connections because the overhead to establish the connection is so much higher. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
