[foaf-protocols] foaf+ssl and hypermedia documents, payload injection

Peter Williams pwilliams at rapattoni.com
Mon Nov 30 19:04:12 CET 2009


The discussion of the so-called SSL renegotiation bug (see http://www.phonefactor.com/sslgapdocs/Renegotiating_TLS.pdf)  is causing lots of folks to study ssl and https internals for the first time (since many assumed that only IETF "experts" would discuss crypto). It's worth understanding the claims of design errors being made today about a 15 year old concept, so we can continue to carefully design foaf+ssl for going forward with the semweb. Foaf+ssl targets linked data environments rather more advanced than the design effort ever intended https for HTML documents et al to serve.  Recall that https is a "profile" of SSL, tuned to deliver a particular set of protections, and there are n variants of https (one per vendor, generally) even for the limited scope of https for browsing the web. Phone Factor happen to discuss some the https properties of some version of IIS webserver (and its particular handling of re-handshaking specifically to obtain "missing" client certs from the session state).

Two statements stand out in the discussion - which is written for generalists. They are worth focusing on (after reading the entire summary). They relate to core design issues for SSL in its intended role (providing for "data confidentiality" AND PROTECTING hypermedia upper layer protocols, specifically). They crucially relate to foaf+ssl, therefore. We get to study in particular the difference between mere "encryption" and the service of "confidentiality". It's crucial, and comes down to payloads (and payload injection). An encrypted sessionid for example (used the hello flow of a full session renegotiation on an existing ssl connection with [even an] encryption security transform) is NOT CONFIDENTIAL material, for example. Its encrypted, but NOT confidential - per the confidentiality policies in effect for sensitive datums.

Read what follows (and its long) ONLY if one has read and understood Phone Factor's summary of SSL for generalists. Only bother if one is REALLY interested in foaf+ssl.



The phone factor summary describes the change cipher spec and finalization process as "The client then establishes an encryption key, each side sends a Change Cipher Spec message to activate encryption, and each sends a Finished request to its peer."

This description of an SSL internal subprocess is more properly analyzed in terms of design goals for a general purpose protection toolkit. Properly said, the parties complete the required key agreement mechanism for CONFIDENTIAL material (e.g. an RSA key transportation under the control of PKI, or the agreement of a TEK in NSA's Fortezza ciphersuite), and must now synchronize their security transform state machines - so activating the "security service" transforms on the 2 TCP/IP half-channels. Both half-channels must be activated with the transforms using the agreed ciphersuite's "security mechanisms," IN ORDER THAT the "finished process" (to come) SHALL MUTUALLY AUTHENTICATE the communication endpoints. MUTUAL AUTHENTICATION of the "parties" is based on PKI (typically) and controls the key agreement mechanism tying parties to one or more confidentiality policies for different sensitivities of data on the channel (where such policies come in and out of effect, on the record layer). MUTUAL AUTHENTICATION of their "endpoints" is based on the properties of the transforms and state machines (not key exchange controls). The persons who are accountable under a "data confidentiality policy" and the communication endpoints that are applying "encryption" security transforms ARE NOT THE SAME THING. (This is all drilled into you if you go to military cipher school, or talk for long to folks who were indoctrinated in that school for applying digital ciphers to data protection on the wire!)

Various records under various payload types may be exchanged during the "finished process" - allowing "extended" mutual authentication of endpoints. (After the finished messages, other payload may be exchanged before the "application payloads" become authorized for transference UNDER CONFIDENTIALITY RULES). But rather than dismissively say that each "just each sends" a finalization message, its vital to understand the finalization process  - and its relevance to the concept called "derivation". The resulting mutual authentication _authorizes_ the exchange of [encrypted] and CONFIDENTIAL application data (in one or more payload/protocol types, tied to one or more confidentiality policies). Presence of any 1 or more application payloads (as defined by profilers of SSL) before the very first finalization on a TCP/IP connection is complete is reason for either side to send a session abort message. Its important to realize the properties of this message. If sent before the ciphersuite become operational, such an abort is NOT authenticated (one should see it as an cleartext extension of the TCP/IP connection's  state machine). It is origin-authenticated if sent after ciphersuite change is complete. If sent after finalization is completed, the abort is then "mutually" authenticated - in the sense that its _intended_ recipient endpoint is "cryptographically" known.  To understand SSL is to understand its abort protocol!

Now, payloads of various types can be being interleaved, during all the above ongoings. For example, two SSL handshakes protocol runs can be being interleaved, when negotiating two (interleaved) SSL session states. For example, one SSL session state binds to the hosts' default namespace, whereas another binds to a particular host's path (which is a cryptographically distinguished subordinate namespace, with its own ssl sessionid). This interleaving of handshakes situation _commonly_ occurs after the first handshake on the TCP connection, and motivated how the changecipherspec messages were formalized in SSL3 (as a non protocol, formally). Some https vendors, on recognizing, interleaving (or "payload injection") during the very first handshake on a TCP connection induce a fatal abort, since there is no endpoint mutual authentication yet.

The phone factor summary goes on to assert that "It is important to note that session resumption seems to have been designed as an optimization, not as a security-related feature of the system."

SSL uses certain cryptographic techniques, including key derivation. Derivation "mechanisms" are analogous to the notion of "subkeys " and "rounds" within a classical Feistel cipher, where a subkey "schedule" is calculated from keying material; to repeatedly mix data in a reversible round process (encryption mixing goes one way through the round schedule, and decryption unmixing goes the other way). Derivation plays the similar role at level of security "service" transform level that subkeys play to cipher-type security "mechanisms". Commonly, derivations of keying material from a master key allow a given (half) channel to rekey itself, so only certain amounts of CONFIDENTIAL plaintext are encrypted under a given piece of derived keying material. This process is not a mere  "optimization". It is critical part of the CONFIDENTIALITY assurances of the design, it is part of finalization. Indeed, in layer 4 security protocol designs more advanced than SSL, n derivations and thus n derived security transforms sets can be operating in parallel on a given channel, where the parallel transforms specifically protect integrity stateful higher-layer protocols. None of this is "an optimization"!

Now to https and foaf+ssl and linked data specifically, where we need to concentrate.

One of the higher layer protocols running through a classical SSL3 channel's "application protocol" is HTTP, which was intended to deliver" hypermedia" representations of resources. HTTP also has a specific (1) CONFIDENTIALY  axis (form posting credit-card PANs and shopping cart contents) and (2) INTEGRITY axis (ensuring a graph's namespace is tied to the location from which the document representation is retrieved.

To allow __parallel__ retrieval of n linked data sets from the data source's authorized root http namespace (all with one SSL3 sessionid, recall), n derived sets of keying material may be computed and each one used on a particular TCP/IP connection. There are logically 1 TCP/IP and 1 SSL connection for each img tag's href ...in the classical HTML root document (allowing parallel streaming of data and parallel "rendering" of resource "graphs"). So, again, none of this SSL design addressing connections and derivation is "an optimization." To the contrary, it's all specifically crafted for the world of linked data.

In that world, SSL payloads of VARIOUS application data types (each with their own SSL protocol number) may be exchanged BETWEEN THE MUTUALLY AUTHENTICATED ENDPOINTS.  Typically, there is only 1, in Netscape compatible https profiles. If inappropriate data is detected (e.g. unauthenticated records, data that fails confidentiality checks, or data of the wrong app protocol) endpoints must abort the SSL connection - using the (mutually authenticated) fatal alert process. Obviously, only authenticated fatal alerts must be acted upon, else any packet router could introduce a alert form message that induces connection teardown. Fatal alerts have key and derirved key desctryption events tied to them that mere TCP/ICP failures do not (and resumable SSL closes do not).

And, now one understand all that, recognize that SSL Sessions (vs connections" may be "duplicated" - in a process that again is specific to the nature of the web. Remember cntrol-N in the netscape browser (and its semantics)? This is Session "duplication" (vs session resumption), and it has handled correctly when handling server state - of the SSL variety and of the more classical CGI-style session state. Now you have two sets of TCP connections claiming control over the SSL3 sessionid. Connections in the second browser instance must now be resumed and new connection keys derived, but ONLY once the browser actually attempts to refresh the now visible "duplicated" graph.

So I hope folks can learn from the original intent of the https design team, and we here can use this understanding for thinking about foaf+ssl and what a foaf card's assertion means post resolution and post de-referencing - for multiple (derived) SSL connections being addressing a particular namespace/sessionid on the data server. The particular claims of design flaws in SSL are not really my concern here, except to say that it was never the intent that an IIS-like webserver would do a client-certificate handshake AFTER the delivery of the confidential HTTP request data. That is a fundamental implementation error, of label-based _confidentiality_ enforcement mechanisms. You CANNOT even decrypt the blob let alone handle the HTTP request (in an APDU), UNTIL you know its confidentiality policy and level. You cannot retain the now labeled datum (an HTTP request), handle it in clear as an authorized party subject now to the confidentiality HANDLING rules, and then go and retroactively apply the new confidentiality policy from a new security context to data labeled under a previous security context! That just elementary design error when delivering Mandatory Access Controls based on ciphering labeled information sets.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20091130/23f66547/attachment-0001.htm 


More information about the foaf-protocols mailing list