[Cryptography] End-to-End Protocols and Wasp Nests

[Dennis E. Hamilton]

  -----Original Message-----
From: Jerry Leichter
Sent: Monday, March 3, 2014 08:28
Subject: Re: [Cryptography] Testing crypto protocol implementations

On Mar 3, 2014, at 2:49 AM, Bill Frantz <frantz at pwpconsult.com> wrote:
>> There are a handful of DANE TLSA test sites, but their "interesting"
>> combinations of certificate chains and TLSA records are far from
>> sufficiently comprehensive.  Lack of a reasonably comprehensive
>> test-bed almost assures that flawed implementations will continue
>> to be produced, and users will continue to use them unaware of
>> their defects.
> 
> It needs to be easy to add "interesting combinations" to the test suite. Good tests of this nature grow as new problem chains, TLSA records etc. are discovered in the wild.
> 
> If it is possible, generating a complete set of combinations of flaws is not unreasonable. I fear that the standards are much too complex for exhaustive testing however.
Indeed.  See http://www.cs.dartmouth.edu/~sergey/langsec/ for some potentially significant work in this direction.  (It'll have to prove itself.)

Response:
 There are interesting and important discussions on [cryptography], inspired by the Apple defect and now GnuTLS, concerning reducing error-proneness and improved inspectability of security-protocol code along with careful scrutiny and testing of components.

With regard to both of those cases, it seems to me that detection and mitigation is not that complex.  Attention to the complexity is important.  But the particular defects were and remain easily detectable with near-blackbox testing at a first-order level.  It seems that there are layers worth considering.

This note looks at it from the end-to-end perspective of the client that may be relying on the protocol incorrectly.

20-20 HINDSIGHT WARNING

I am assuming that the defects that have been so startling revealed are applicable to client-side agents relying on SSL/TLS incorrectly.  It is not a penetration case, it is an impersonation, false-acceptance case.  (That is, improper confirmation of the server, not of the client.)

Consider a Wasp Nest (no honey) set up to provide the following: locally accessible DNS, possibly for impossible TLDs. Web sites (running on the same box for simplicity) that deliver a variety of correct and incorrect TLS connections, whether involving wrong-origin certificates, correct-origin certificates, and protocol-handshake and data defects of various kinds.

Scripts can be used from a test client to confirm that the Wasp Nest is behaving as designed (including its incorrect responses and certifications).  This should be maintainable.

Now one can access the Wasp Nest from devices to determine that those user agents are dealing with the Wasp Nest sites resiliently and properly.  

This fixture is easily updated with more cases that may become known and important.  It should not be exposed on the public internet of course, but it should be simple enough to use on a private (inter)net and via WiFi from non-wired devices.  For devices tied to cellular services, one would hope that there is common code in the user agent and that it could be tested in a form that accesses the Wasp Nest.  

I don't like "isn't it a Simple Matter of Programming?" requests from the uninformed, and I trust that I have not introduced a security-protocol SMOP equivalent.

 - Dennis