See also SKIP-TLS: https://www.smacktls.com/#skip
On Thu, Mar 5, 2015 at 3:22 PM, <travis+ml-lang...@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@mail.langsec.org > https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss > > -- Tony Arcieri
_______________________________________________ langsec-discuss mailing list langsec-discuss@mail.langsec.org https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss
