https URL resolution has a specific security model, designed around hypermedia. (You won't see any of this stated much, if at all, in IETF documents).
If, alternatively, one invokes ssl in an existing http connection for example (using the appropriate Upgrade headers per RFC 2817), one does not get https "URL resolver" semantics. That existing http connection (already resolved using some or other URL scheme, including the resolver protocols performing trusted XRI->HXRI rewriting) may or may not be handling a hypermedia document, of course. In spite of that, RFC2817 can still apply "transport level security" to the flow of bits across (2) half-duplex pipes formed across TCP-layer connection - enabling the HTTP request or HTTP reply to be transported under the control of a particular security context in the SSL session MIB. If the application handling those http flows opts to do a half-close on 1 TCP channel, obviously SSL integrity/encipherment would occur now in only one flow direction (std MITM spying/interception technique by ISPs, executed at the proxy). SSL was carefully designed for TCP, recall, with its 2 pipe and half-close semantics, its OOB messages (useful for spying n the handshake), and (later) TCP/HTTP keep-alives.
In the case of a frame/iframe (a HTML-specific hypermedia notion, per se) the hypermedia-centric https semantics only come into play when the application properly handles hyper-media. IN the case of frames, the **outer** document type is obviously HTML. The document within the frame/iframe, if HTML (or Microsoft's own Word engine or Adobe's own pdf engine, or other hypermedia document engine DESIGNED to cooperate with https semantics) can instantiate its own https sessions/connections - independent of the higher-level document (and each get their own security contexts in the https state machine). IN short, any link connections made to "render" the HTML stream of a *particular* HTML document get resolved according to the https session of the parent frame/iframe (but not the outer document's own frame's security context, if any).
I don’t know if SAML2 websso or the "Shib-cookie over https" scheme was properly designed with https semantics in mind. The underlying SAML session-translation model is cute, but how rigorous its formal security model it is with respect to https semantics is not obvious - and its unknown (to me, anyways). XML1.0 is a hypermedia-capable markup, of course; but in its SOAP profiles its less obvious if S2ML/SAML over SOAP/POST/Redirect is supposed to invoke hypermedia document handling that https was designed for.
For what it's worth, Google security engineers seem to have a good handle on the original security model. They understand the relationship between the sandbox model, the hypermedia model, and the way one has to compartmentalize the UA's security contexts (by frame/process) when working across multiple SSL sessions. How they will accomplish this without relying on OS support (to provide B2-level process isolation) I don’t know. But, its all good fun!
My flame shield now up; since my comments on this https+hypermedia topic always provoke derision. **Secure** cookies (those bearing the secure flag, that is) are another favorite topic for flaming, as they too require good understanding of the https __hypermedia-centric__ security model.
-----Original Message-----
From: Scott Cantor [mailto:***@osu.edu]
Sent: Monday, September 01, 2008 12:09 PM
To: shibboleth-***@internet2.edu
Subject: RE: [Shib-Users] Call login using a IFRAME
Post by Chad La JoieYeah, I'm pretty sure this is an issue with IFRAMEs not sending cookies
like a normal frame would. Scott and I were talking about this the
other day for other reasons. You'll need to read up on IFRAMEs and how
your browser handles them.
Particularly when SSL is involved. Our experience at OSU, with fairly minimal testing, is that frames are unusable with cookie-based applications when SSL is used (unless all the frames are coming from the same server of course), and we haven't spent much time trying t