[squid-dev] [PATCH] initial GnuTLS support for encrypted server connections

[Amos Jeffries]

On 3/02/2017 4:05 a.m., Alex Rousskov wrote:
> On 02/01/2017 11:51 PM, Amos Jeffries wrote:
> 
>> Can we agree on this being a fundamental design in Squid:
>>
>>  * all connections have an associated socket ID.
> 
> That assumption would be too limiting (and, AFAICT, unnecessary). For
> example, SSL connections inside SSL connections (HTTPS proxy) do not
> have a socket. The same will apply to SSL connections inside HTTP/2
> sessions. And eventually QUIC.
> 

I know. However the curent Squid code does not support such things.
Probably _because_ it was designed with the above as one of the assumptions.


> 
>>  * all _open_ connections are stored in fd_table. Indexed by the
>> connections socket ID. If not that is a bug.
> 
> Again, this is oversimplifying too much: fd_table is for sockets, not
> connections.

This is why I emphasized _open_ connections. The connections without
socket ID (FD number) are represented by Comm::Connection in 'closed'
state (fd == -1).

If there are other types of connection in the current codebase please
point me at them.



> Some connections do not have sockets. All open TCP
> connections should have sockets in fd_table though.
> 
> 
>> Do you agree on that?
> 
> No.
> 



> 
>> Now a Question, and please answer carefully:
>>
>> Does the PeerConnector or the new() operator 'connect' the "SSL
>> connection" ?
> 
> Which new() operator?

SSL_new() - the one being called by Ssl::CreateClient() to produce its
return object.

OpenSSL:
 "structure which is needed to hold the data for a TLS/SSL connection"

This is the object which will become the Squid representation of a
"session" [see below]. Although at the time of the Create*() function
return it is only half (or less) the session data and is definitly not
associated with a "connection" (yet).


> To connect an SSL connection one has to call
> SSL_connect() or equivalent.

Um, the SSL_connect() function performs the TLS/SSL handshake protocol.

Note sentence 2 of the formal definition:
"
   session
      A TLS session is an association between a client and a server.
==>   Sessions are created by the handshake protocol.  Sessions define a
      set of cryptographic security parameters that can be shared among
      multiple connections.  Sessions are used to avoid the expensive
      negotiation of new security parameters for each connection.
"


> If PeerConnector or your new() operator
> call SSL_connect() (directly or indirectly) then they are trying to
> change the state of an SSL connection to "connected".

This again diverges from the RFC 5246 definition:
"
   connection
      A connection is a transport (in the OSI layering model definition)
      that provides a suitable type of service.  For TLS, such
      connections are peer-to-peer relationships.  The connections are
      transient.  Every connection is associated with one session.
"

The section 6.1 which introduces the phrase "TLS connection" as a
concept is documenting the "TLS Record Protocol". It is very clear that
abstract "TLS connection" does not exist until the TLS records are
flowing. At which point it refers the transport protocol stack, with
"TLS Record Protocol" on top of that stack.

The session is different:
"
   session
      A TLS session is an association between a client and a server.
      Sessions are created by the handshake protocol.  Sessions define a
      set of cryptographic security parameters that can be shared among
      multiple connections.  Sessions are used to avoid the expensive
      negotiation of new security parameters for each connection.
"

... and also because "Record Protocol" (aka "TLS connection") exists and
can be used (often are - for alerts etc.) without the handshake having
taken place nor a "session" existing.

(I am of course assuming that since you pointed me at that RFC for
references of "SSL connection" - which does occur exactly 0 times in
that document - that you mean "TLS connection" when you write "SSL
connection").


> Does that answer
> your question?
> 

Sadly no, but in a way yes. Earlier you grumbled about conflating "SSL
session" with "SSL connection".

The only conflation I am seeing is in the OpenSSL documentation. The
spec does not define the term at all, and the closest equivalent is a
phrase used to abbreviate the transport description - not anyting crypto
related.

So far as I can tell both the existing v5/v4 code and my patches do
match the definitions in the RFC 5246 for "session", "connection", and
the fuzzy "TLS connection".

Amos