1. 13 Jun, 2012 1 commit
  2. 11 Jun, 2012 2 commits
  3. 08 Jun, 2012 1 commit
  4. 07 Jun, 2012 3 commits
  5. 29 May, 2012 1 commit
  6. 14 May, 2012 2 commits
  7. 13 May, 2012 1 commit
  8. 10 May, 2012 1 commit
  9. 14 Dec, 2011 1 commit
  10. 12 Dec, 2011 1 commit
  11. 05 Nov, 2011 1 commit
  12. 03 Nov, 2011 1 commit
  13. 22 Sep, 2011 2 commits
  14. 15 Sep, 2011 1 commit
    • David Woodhouse's avatar
      Clean up DTLS timer workaround to make it work with Debian OpenSSL, hopefully · 269a2e16
      David Woodhouse authored
      The Debian libraries don't export dtls1_stop_timer() since it's supposed to
      be an internal function. But thankfully I think we can do it manually. This
      sucks; it means that a misguided attempt at restricting us has forced us
      into poking at even *more* internal stuff than we ever wanted to. Yay Debian.
      Try to make it slightly less insane by putting upper and lower bounds on
      the versions for which we'll do it: We know that OpenSSL 1.0.0e and
      above won't be resending the ChangeCipherSpec messages anyway, because
      of the fix for OpenSSL RT#2505. I'm dubious about that being the correct
      thing to do, but it's working and it matches the Cisco client so I'm going
      to try not to think about it too hard.
      Also stop *defining* SSL_OP_CISCO_ANYCONNECT for ourselves, and simply
      refuse to build DTLS support if it's absent. That patch is merged into
      OpenSSL long ago, so we are effectively requiring 0.9.8m or above.
      That version is, by coincidence, also the first version where our own
      dirty reimplementation of dtls1_stop_timer() is valid. If someone does
      backport the Cisco compatibility patch to even-more-ancient OpenSSL than
      that, they'd best make sure they backport the other fixes too.
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
  15. 08 Sep, 2011 1 commit
    • David Woodhouse's avatar
      Fix DTLS compatibility with ASA firmware 8.4.1(11) and above. · 9785d0c0
      David Woodhouse authored
      It seems to get very upset when we resend our ChangeCipherSpec messages,
      as the RFC says we're supposed to do. Without a periodic resend, if the
      original did get lost in transit, the server wouldn't be able to decrypt
      any of our data packets.
      Perhaps there's something "wrong" with our packets; the ChangeCipherSpec
      messages is is one of the areas in which Cisco's "speshul" version of
      DTLS differs from RFC4347. But the Cisco client doesn't seem to resend it
      at all, ever. Making it hard to tell what Cisco want it to look like,
      unless we wanted to reverse-engineer their code. Which we don't.
      If Cisco get away without resending, I suppose we can, until/unless we
      work it out. DPD should mostly let us get away with it, because if the
      first packet *does* get lost, DPD will soon tell us that the DTLS
      connection is dead and we'll make a new one. Sucks, but that's what you
      get for using crappy not-quite-RFC-compliant kit. Yay Cisco. Why not join
      us in 2006 and start using the proper standard? It's not even as if it'd
      be hard to support both in parallel for a while.
      Thanks to Eric Barkie for the initial diagnosis.
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
  16. 27 Jun, 2011 1 commit
  17. 09 Mar, 2011 1 commit
  18. 11 Aug, 2010 1 commit
    • David Woodhouse's avatar
      Implement DTLS and CSTP rekeying. · 9d2b41dc
      David Woodhouse authored
      Don't know if there's a way to pass a new DTLS master secret and get
      back a new session-id over an existing CSTP connection; reconnecting the
      CSTP works though. And is the way to rekey CSTP too, since SSL
      renegotiation got deprecated (we never got round to doing it that way
      either, anyway).
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
  19. 07 Aug, 2010 1 commit
  20. 14 Apr, 2010 1 commit
  21. 11 Apr, 2010 1 commit
  22. 24 Mar, 2010 1 commit
  23. 02 Jan, 2010 2 commits
  24. 01 Jan, 2010 1 commit
  25. 17 Nov, 2009 1 commit
  26. 02 Nov, 2009 1 commit
  27. 03 Oct, 2009 1 commit
  28. 23 Jun, 2009 1 commit
  29. 10 Jun, 2009 1 commit
  30. 02 Jun, 2009 1 commit
  31. 01 Jun, 2009 1 commit
  32. 27 May, 2009 1 commit
  33. 24 Apr, 2009 1 commit
  34. 18 Apr, 2009 1 commit