pcp
[Top] [All Lists]

Re: [pcp] Secure Client/Server Features Confusion

To: Dave Brolley <brolley@xxxxxxxxxx>
Subject: Re: [pcp] Secure Client/Server Features Confusion
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Tue, 5 Aug 2014 19:43:31 -0400 (EDT)
Cc: PCP Mailing List <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <53E15244.4000402@xxxxxxxxxx>
References: <53E15244.4000402@xxxxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: 96RwUSVTRVN9ASbfD4IHjjok1cfKnQ==
Thread-topic: Secure Client/Server Features Confusion
Hi Dave,

----- Original Message -----
> [...]
> So the question is, do we need an SSL/TLS file descriptor in order to support
> compression, or just an NSPR file descriptor. It looks to me like SSL is
> needed for compression, but I need to know for sure so that I know under
> which conditions to initialize NSS in addition to NSPR.

My understanding is that in terms of implementation in NSS/SSL, the compression
support is tied to having an SSL connection.  However at the time this code was
added to PCP, it seemed prudent to make this a general flag (as opposed to say,
PDU_FLAG_SSLCOMPRESS) since we may need to implement compression independently
at some point (e.g. like here - http://sean-graham.com/2001/05/09/nspr-is-neat/
or even over the native socket interfaces).

So, in the current implementation the two are intimately tied to each other -
maybe it will always be that way, maybe not.

> While we're at it, is there any relationship between these flags and
> PDU_FLAG_AUTH (SASL?). i.e. is a secure connection required for
> authentication?

No relationship.  However, somewhere in there we do need to tell SASL what the
'security strength factor' of the underlying transport is - see sasl_setprop()
with SASL_SSF_EXTERNAL over in __pmAuthServerSetProperties - and that "ssf" is
extracted from NSS/SSL earlier on.  Other than that place, the two components
are blissfully unaware of each other.

cheers.

--
Nathan

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