[langsec-discuss] state machine attacks against TLS (SMACKTLS)

Tony Arcieri bascule at gmail.com
Sat Mar 7 23:29:18 UTC 2015

See also SKIP-TLS:


On Thu, Mar 5, 2015 at 3:22 PM, <travis+ml-langsec at subspacefield.org> wrote:

> https://www.smacktls.com/
> So, I haven't looked at the JSSE (that is, JDK) implementation of TLS,
> but I'm guessing that based on the number of erroneous transitions,
> they implemented an ad-hoc state machine interwoven with the code
> rather than modeling the FSM abstractly with explicit calls to make
> transitions.  I am sure this sounds familiar to the readers of this
> list, as the state machine is the state of the network data parser.
> My intuition tells me that a large number of protocols could be
> handled in a much safer by encoding a formal FSM with named
> transitions that are explicitly invoked from the software and which
> throw exceptions back if the transition is not allowed.  Further by
> decoupling the FSM & associated client state from the software it
> should be much easier to drive multiple state machines at once with a
> single network daemon*.
> If you were to do that you might be able to factor the parser out
> (possible also for formal treatment) and have a single daemon handling
> multiple services for multiple clients (a la inetd and the old
> stateless services it handled directly).  One could then potentially
> limit resource consumption for a single client across services to
> prevent resource consumption attacks.  This was a bigger deal when I
> thought of it in the 90s; now most servers are single-purpose.
> [*] OS interactions such as assuming a given effective userid, or
> irrevocably dropping permissions would be difficult, but possible if
> one factored the "OS actor" out into its own component (each FSM would
> have exactly zero or one of these as appropriate for the service being
> handled).
> In the case of safe languages and frameworks (erlang?), one could run
> the protocol parser in a common memory space and avoid security
> (process) boundary transition overhead (e.g. IPC overhead, scheduler
> latency, TLB flush).  Similarly the FSMs could be handled directly in
> the process space as well.  In the case of the OS actor, that must
> necessarily be its own process context, but shared memory or zero-copy
> IPC like that used by L4 microkernel could reduce that overhead
> significantly.  The entire ecosystem might be modelable as a message
> passing architecture.
> This idea's pieces have been sitting undone on my list here:
> http://www.subspacefield.org/~travis/good_ideas.html
> Specifically, the 90s-influenced use cases:
> Write a network daemon in a "safer" language than C (java, perl,
> python, ML). See privilege.py for example of how to drop privileges
> safely.
> Write something like tcpdump or wireshark, but write the protocol
> decoding routines in a safer language. ruby and python come to mind,
> but ocaml might be faster.
> --
> http://www.subspacefield.org/~travis/
> "Computer crime, the glamor crime of the 1970s, will become in the
> 1980s one of the greatest sources of preventable business loss."
> John M. Carroll, "Computer Security", first edition cover flap, 1977
> _______________________________________________
> langsec-discuss mailing list
> langsec-discuss at mail.langsec.org
> https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss

Tony Arcieri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.langsec.org/pipermail/langsec-discuss/attachments/20150307/e18768af/attachment.html>

More information about the langsec-discuss mailing list