Re: [Pan-users] gnutls error: hostname does not match server name

[Duncan]

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