Benjamin Kaduk wrote: [ Charset windows-1252 unsupported, converting... ] > On 11/10/2016 11:13 AM, Martin Rex wrote: > > > > There is a concept called "provable correctness", and folks (such as > > those from the miTLS implementation) are using this approach to check/prove > > whether TLS provides certain security properties (rather than just > > assuming that these properties are provided). > > > > If hiding of ContentType has *real* value, then this property will be > > formally provable. If the properties that someone asserts as value > > can be proven to not exist (one counterexample is sufficient), > > then the value is an illusion / obscurity, and definitely not real value. > > My understanding was that our current knowledge of what capabilities > traffic analysis makes possible and the countermeasures against them is > quite poor, certainly not to the level where rigorous proofs are > possible. So, I fear we must be operating "in the dark" in this regard > for the near future.
Proving that something is secure can be pretty difficult, that is correct. Proving that something is insecure can be pretty trivial (one counterexample is sufficient). For someone who does this formal proofing stuff regularly, it may already be possible today to formally proof that hiding the ContentType can not possibly provide any value. Where is the value with hiding the ContentType of SSL Alerts? We know that at least one implementations notoriously _not_ sends any alerts before closing connnections. The installed base has somehow managed to live with it. But it's often painful to figure out the cause of handshake failures, and to distinguish a certain kind of server accept()ing and silently closing a connection after hitting a bug (or policy) from an overzealous firewall (NAT or "transparent internet proxy"). So if your implementation has anything to hide, performing a dirty socket closure (resulting in a TCP RST) will be *MUCH* more effective in hiding information from observers than hiding the TLS Alert ContentType. Silent connection closures are certainly much more effective for leaving rightful communication peers (&helpdesk &support) in the dark about why the heck communication is failing. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
