On Mon, Nov 30, 2009 at 1:07 PM, Ian G <i...@iang.org> wrote: > I agree. It breaches that fundamental law of the Iang's mind-space: there > is only one mode, and it is secure. Break the law, time folds and inverts > on itself, and Mallory slips between your bytes.
'secure' is a state of mind, not too different from 'paranoid'. The trade-off is in the amount of time you have to spend assessing everything as a potential threat. > > Old military trick: attack between. > > Ok, maybe not that dramatic, nobody got breached and nobody died, but it > does seem illogical to add options to such a foolish extent. Adding options > without a clear demand & use-case is just asking for trouble. Twitter was breached. Before they disabled renegotiation on their servers, the status message POST update was POST [...], and then their Basic-encoded username and password. Someone injected prior bytes before allowing the renegotiation, and every time someone was intercepted, that someone's status message changed to a whole bunch of usernames and passwords. > Shamefully, there's a lot of it going on in the protocol committees. One > wonders whether there is a correlation between the number of options and the > number of jobs... The capability for TLS to renegotiate securely was missing in the protocol, and it's obvious in hindsight. However, relying on renegotiation to provide different levels of authentication/security to different areas of the URL space without requiring the full request to be resubmitted under the new credentials... It's called "Defense In Depth" for a reason. Don't rely on any particular aspect of your system going unbreached. Don't rely on an underlying protocol to do precisely what you (and its designers) expect. And don't design protocols that allow a single request to be submitted across two different authentication levels. My thought is this: if Apache needs to do a renegotiation, it should *always* send a 302 header to have the client go where it thought it needed to go. (It sucks to not be able to rely on the original URL that was requested, since it came in under an unauthenticated cover, but if there was a way in HTTP for the server to request to the client that it reissue the request that it thought it sent... but that's a bug in HTTP, and we don't talk about HTTP here.) -Kyle H -Kyle H -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
