pcp
[Top] [All Lists]

Re: [pcp] Secure sockets builds have high daemon memory utilisation

To: Nathan Scott <nathans@xxxxxxxxxx>
Subject: Re: [pcp] Secure sockets builds have high daemon memory utilisation
From: Dave Brolley <brolley@xxxxxxxxxx>
Date: Tue, 02 Sep 2014 12:57:57 -0400
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <1340890868.34561257.1408489421876.JavaMail.zimbra@xxxxxxxxxx>
References: <1896810420.23212457.1402370819966.JavaMail.zimbra@xxxxxxxxxx> <5397573A.90102@xxxxxxxxxx> <53EBCCEB.2030604@xxxxxxxxxx> <1306085089.30466668.1408001833620.JavaMail.zimbra@xxxxxxxxxx> <53F245A1.2070003@xxxxxxxxxx> <1131406976.33656824.1408432815577.JavaMail.zimbra@xxxxxxxxxx> <53F3A80F.6010204@xxxxxxxxxx> <1340890868.34561257.1408489421876.JavaMail.zimbra@xxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0
On 08/19/2014 07:03 PM, Nathan Scott wrote:

----- Original Message -----
[...]
Right. The server does attempt to send an error pdu but, because NSS
init failed, it sends it over the existing insecure socket connection.
Meanwhile, the client has already upgraded to a secure socket and is
expecting the SSL handshake. I think that this is why the connection
ends up getting dropped by NSS.

Note that the error pdu is only sent in the case that there is an error.
Perhaps what needs to happen is that something should be sent back to
the client on the insecure connection in all cases, essentially saying,
"yes, go ahead and upgrade" or "no, there's been an error". Only then
would the client and server be able to stay in sync in the event that
the server cannot upgrade. Unfortunately that would be a protocol change.
Ah, OK, got it.  It could (would have to) be done as a PDU_FLAG_SECURE_ACK
extension, perhaps?  Alongside the existing PDU_FLAG_SECURE - so existing
clients using secure connections would get ECONNRESET, but all newer ones
would get the clean error handling extension.

IOW, pmcd would set both flags in the initial exchange, old clients would
be oblivious, and new clients would be able to wait on ACK/error PDU before
entering into the full SSL exchange... ?


OK. The commit below (brolley/dev in pcpfans) is an implementation of this. When supported by both the client and the server, an error pdu is sent from the server to the client during the secure connection handshake which indicates whether the server is able to honour the client's request for a secure connection. If either the client or server does not support this then this part of the handshake is neither expected nor performed.

Passes qa qith no regressions. Also tested with old clients and new servers and vice versa. pmproxy has also be tested under these conditions.

Dave

Author: Dave Brolley <brolley@xxxxxxxxxx>
Date:   Tue Sep 2 10:47:23 2014 -0400

    Implement new PDU_FLAG_SECURE_ACK protocol for clients and servers.

    When the server supports it, clients can request that an error
    pdu indicacting the server's NSS and SSL initialization status
    be sent by the server as part of the secure connection handshake.
    This indicates whether the server is able to upgrade its connection
    to SSL/TLS and, thus, whether the client should do the same.

    Older servers will not indicate this capability during the initial
    handshake and so the client will not request or expect the pdu.
    Older clients will not request this and the server will therefore
    not send the pdu.

<Prev in Thread] Current Thread [Next in Thread>