<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 12/16/13 10:36 PM, Patrick Kelsey
      wrote:<br>
    </div>
    <blockquote cite="mid:C620055B-AFFF-4B4E-A226-301293177250@ieee.org"
      type="cite">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div><br>
      </div>
      <div><br>
        On Dec 16, 2013, at 9:33 PM, Juli Mallett <<a
          moz-do-not-send="true" href="mailto:juli@clockworksquid.com">juli@clockworksquid.com</a>>
        wrote:<br>
        <br>
      </div>
      <blockquote type="cite">
        <div>
          <div dir="ltr">
            <div class="gmail_extra">
              <div class="gmail_quote">On Mon, Dec 16, 2013 at 6:29 PM,
                Alfred Perlstein <span dir="ltr"><<a
                    moz-do-not-send="true"
                    href="mailto:alfred@freebsd.org" target="_blank">alfred@freebsd.org</a>></span>
                wrote:<br>
                <blockquote class="gmail_quote" style="margin:0 0 0
                  .8ex;border-left:1px #ccc solid;padding-left:1ex">
                  <div bgcolor="#FFFFFF" text="#000000">
                    <div class="im"> <br>
                      <div>On 12/16/13, 4:28 PM, Juli Mallett wrote:<br>
                      </div>
                      <blockquote type="cite">
                        <div dir="ltr">Alfred,
                          <div><br>
                          </div>
                          <div>It's probably the "libuinet" component
                            you're looking for, but that's an active
                            userland TCP stack, not a passive one.  That
                            is, you can do full TCP/IP with libuinet
                            pretty easily, but you can't just hand it
                            packets and look at a stream you're
                            intercepting.  It might be possible to make
                            it provide two half-connections for each
                            connection from the wire at some point, with
                            data going into a socket and being readable,
                            but that functionality isn't there now.  I
                            know there's some interest in funding Pat
                            Kelsey (who did the "libuinet" work) to do
                            that, but I don't think there's any roadmap
                            for it.  I may also be misunderstanding what
                            you're using libnids to do.</div>
                        </div>
                      </blockquote>
                      <br>
                    </div>
                    I think you're right on point.<br>
                    <br>
                    Basically what I need is the ability to write
                    something like <a moz-do-not-send="true"
                      href="https://github.com/alfredperlstein/dsniff/blob/master/urlsnarf.c"
                      target="_blank">https://github.com/alfredperlstein/dsniff/blob/master/urlsnarf.c</a>
                    using wanproxy as a backend.<br>
                    <br>
                    Specifically have a look at line 164 of the file at 
                    sniff_http_client(), this calls line 88 of that file
                    (process_http_request()) each time a new packet
                    comes in for a stream we are interested in.  It's
                    relatively basic stuff to monitor streams.  Is it at
                    all possible to do this using wanproxy libuinet?<br>
                  </div>
                </blockquote>
                <div><br>
                </div>
                <div>Nope, not at this time, unless you're willing to
                  actually be an inline proxy instead, which is probably
                  not worth it since libnids exists.</div>
                <div> </div>
                <blockquote class="gmail_quote" style="margin:0 0 0
                  .8ex;border-left:1px #ccc solid;padding-left:1ex">
                  <div bgcolor="#FFFFFF" text="#000000"> If not is Pat
                    available to chat about what needs to be done?<br>
                  </div>
                </blockquote>
                <div><br>
                </div>
                <div>I've added him to the CC list explicitly, I'm sure
                  he has some thoughts on how possible it would be to
                  adapt the FreeBSD stack to support passive reception /
                  read-only connections.</div>
              </div>
            </div>
          </div>
        </div>
      </blockquote>
      <br>
      <div>Thanks, Juli.  It's a wonder I hadn't subscribed to the list
        until ten minutes ago.</div>
      <div><br>
      </div>
      <div>libuinet currently has the ability to flexibly listen for TCP
        connections, letting you independently specify any/single for IP
        address, port, and VLAN tag stack.  Inbound connection attempts
        that make it past that selector can be additionally qualified by
        a user-supplied filter routine that has access to all the L2 and
        L3 address information on the SYN.  Whatever passes those
        criteria becomes a connection accessible via the sockets API,
        and whatever doesn't pass is blackholed.</div>
      <div><br>
      </div>
      <div>The 'sockets API' above is currently the FreeBSD in-kernel
        API.  If you aren't familiar, suffice it to say it's
        event-driven, so it lends itself to urlsnarf-style applications.
         You'd also have the option of using the WANproxy event system
        and sockets API, as that is now integrated with the libuinet
        API.</div>
    </blockquote>
    <blockquote cite="mid:C620055B-AFFF-4B4E-A226-301293177250@ieee.org"
      type="cite">
      <div><br>
      </div>
      <div>So the only thing truly lacking is receive-only socket
        functionality.  Off the top of my head, this would require
        plumbing  through a new socket option for listen sockets, that
        when enabled, would modify the TCP state machine for inbound
        connections (3-way handshake becomes 1-way handshake),
        modify/disable some timer behavior, silence all outbound ACK,
        FIN and RST paths, deal with anything dependent on RTT and the
        ability to limit the client's behavior based on options
        negotiation...</div>
    </blockquote>
    <br>
    I think this is what is needed, basically a "tap/tee" socket so that
    our application can watch an established flow.<br>
    <br>
    Imagine:     <br>
    <br>
    client  <->  [switch] <-> server<br>
                            |<br>
    application <-span port-><br>
    <br>
    Our application would then be able to monitor the existing streams.<br>
    <br>
    Basically the functionality that seems best would be getting a
    libnids-like callback with a tcp structure that maintains a copy
    buffer of the data transferred until we tell it to discard.<br>
    <br>
    <blockquote cite="mid:C620055B-AFFF-4B4E-A226-301293177250@ieee.org"
      type="cite">
      <div><br>
      </div>
      <div>Some consideration would have to be given to whether and how
        to handle dropped frames that would leave a hole in the
        reassembled stream, unless it's reasonable to assume that the
        data path that would be feeding this suffers no more losses
        (lossy driver input queues, oversubscribed span ports, etc) than
        the path to the responding party at the true other end of the
        connection.</div>
    </blockquote>
    I think we need to deal with lossy/out of order at least at a basic
    level.<br>
    <br>
    <blockquote cite="mid:C620055B-AFFF-4B4E-A226-301293177250@ieee.org"
      type="cite">
      <div><br>
      </div>
      <div>Not trivial, but I think entirely doable.  I'd be happy to
        talk more about it, if this at all seems on the track to what
        you are after.</div>
    </blockquote>
    I think so.  I'm going to send a follow up off-list so we can
    exchange contact information and see how we can make this happen.<br>
    <br>
    thank you,<br>
    -Alfred<br>
  </body>
</html>