On Wed, 20 Jun 2012 12:46:19 -0400, Dave Brolley wrote:
brolley> The use of NSS/NSPR on its own does not provide SSL/TLS
brolley> connections. The client and server must both agree to and
brolley> expect the use of a secure connection. The idea would be to
brolley> have an insecure connection made as normal and then to
brolley> provide some sort of protocol by which the client and/or
brolley> server can request an upgrade to a secure connection (think
brolley> STARTTLS). In this way existing pmcd clients and agents can
brolley> still connect to pmcd without change and future clients and
brolley> agents can still use insecure connections if they choose.
Couple of things to note:
1. What is the 'killer app' for secure connection? I know Frank and
Mark had talked in the past about the need to "authenticate"
clients to be able to provide finer granied access control.
If this is the real driver behind this work then I think some sort
of strawman to how how it can work end-to-end, i.e. how can pmcd
verify that it knows the client would go a very long way in proving
that the abstraction actually makes sense.
Otherwise it's just 'everything must be encrypted' mantra which
doesn't really make sense when talking about performance
monitoring - think of Schroedinger's cat.
2. In PCP world pmcd can send unsolicited PDU to the client. This kind
of communication does not map well on STARTTLS-like paradigm unless
you're planing to delay STARTTLS phase until after connection
handshake is done.
3. Who's going to decide what it's time to 'starttls'? Usually it's
the 'client' decision but client needs to know that server is
capable of this. How is it going to be communicated to the client?
brolley> A second issue is that many components use sockets, files
brolley> and pipes seamlessly and that file descriptors representing
brolley> all of these are passed to some functions. As a result,
brolley> these functions must use the abstracted data types and I
brolley> have had to extend the POSIX-NSS/NSPR abstraction to normal
brolley> file and pipe I/O in many cases. I have, so far, left as
brolley> much code as I can unabstracted, however, for the sake of
brolley> consistency, it may make sense to convert all I/O (at least
brolley> within the pmcd) to use the abstraction layer.
I thought that Nathan has already gone and done the necessary changes
to separate functions which deal with real sockets from functions
which deal with 'other stuff' like file descriptors as part of Windows
port.
max
|