Skip to content
  1. Feb 16, 2001
  2. Feb 15, 2001
  3. Feb 14, 2001
  4. Feb 13, 2001
  5. Feb 12, 2001
    • Dr. Stephen Henson's avatar
      Modify OCSP nonce behaviour. · 46a58ab9
      Dr. Stephen Henson authored
      46a58ab9
    • Dr. Stephen Henson's avatar
      Work around for libsafe "error". · 94fcd013
      Dr. Stephen Henson authored
      94fcd013
    • Geoff Thorpe's avatar
      Re-order a couple of static functions and "#if 0" out unused ones - this · 9a043873
      Geoff Thorpe authored
      gets rid of gcc warnings.
      9a043873
    • Geoff Thorpe's avatar
      This change was a quick experiment that I'd wanted to try that works quite · 282d8b1c
      Geoff Thorpe authored
      well (and is a good demonstration of how encapsulating the SSL in a
      memory-based state machine can make it easier to apply to different
      situations).
      
      The change implements a new command-line switch "-flipped <0|1>" which, if
      set to 1, reverses the usual interpretation of a client and server for SSL
      tunneling. Normally, an ssl client (ie. "-server 0") accepts "cleartext"
      connections and conducts SSL/TLS over a proxied connection acting as an SSL
      client. Likewise, an ssl server (ie. "-server 1") accepts connections and
      conducts SSL/TLS (as an SSL server) over them and passes "cleartext" over
      the proxied connection. With "-flipped 1", an SSL client (specified with
      "-server 0") in fact accepts SSL connections and proxies clear, whereas an
      SSL server ("-server 1") accepts clear and proxies SSL. NB: most of this
      diff is command-line handling, the actual meat of the change is simply the
      line or two that plugs "clean" and "dirty" file descriptors into the item
      that holds the state-machine - reverse them and you get the desired
      behaviour.
      
      This allows a network server to be an SSL client, and a network client to
      be an SSL server. Apart from curiosity value, there's a couple of possibly
      interesting applications - SSL/TLS is inherently vulnerable to trivial DoS
      attacks, because the SSL server usually has to perform a private key
      operation first, even if the client is authenticated. With this scenario,
      the network client is the SSL server and performs the first private key
      operation, whereas the network server serves as the SSL client. Another
      possible application is when client-only authentication is required (ie.
      the underlying protocol handles (or doesn't care about) authenticating the
      server). Eg. an SSL/TLS version of 'ssh' could be concocted where the
      client's signed certificate is used to validate login to a server system -
      whether or not the client needs to validate who the server is can be
      configured at the client end rather than at the server end (ie. a complete
      inversion of what happens in normal SSL/TLS).
      
      NB: This is just an experiment/play-thing, using "-flipped 1" probably
      creates something that is interoperable with exactly nothing. :-)
      282d8b1c
  6. Feb 11, 2001
  7. Feb 10, 2001
  8. Feb 09, 2001
  9. Feb 08, 2001