Skip to content
Snippets Groups Projects
  1. Dec 05, 2014
  2. Dec 01, 2014
  3. Nov 19, 2014
  4. Nov 18, 2014
  5. Oct 24, 2014
  6. Jul 16, 2014
    • David Woodhouse's avatar
      Remove all traces of FBOpenSSL SPNEGO support · 9ad282b1
      David Woodhouse authored
      This is just fundamentally broken. SPNEGO (RFC4178) is a protocol which
      allows client and server to negotiate the underlying mechanism which will
      actually be used to authenticate. This is *often* Kerberos, and can also
      be NTLM and other things. And to complicate matters, there are various
      different OIDs which can be used to specify the Kerberos mechanism too.
      
      A SPNEGO exchange will identify *which* GSSAPI mechanism is being used,
      and will exchange GSSAPI tokens which are appropriate for that mechanism.
      
      But this SPNEGO implementation just strips the incoming SPNEGO packet
      and extracts the token, if any. And completely discards the information
      about *which* mechanism is being used. Then we *assume* it was Kerberos,
      and feed the token into gss_init_sec_context() with the default
      mechanism (GSS_S_NO_OID for the mech_type argument).
      
      Furthermore... broken as this code is, it was never even *used* for input
      tokens anyway, because higher layers of curl would just bail out if the
      server actually said anything *back* to us in the negotiation. We assume
      that we send a single token to the server, and it accepts it. If the server
      wants to continue the exchange (as is required for NTLM and for SPNEGO
      to do anything useful), then curl was broken anyway.
      
      So the only bit which actually did anything was the bit in
      Curl_output_negotiate(), which always generates an *initial* SPNEGO
      token saying "Hey, I support only the Kerberos mechanism and this is its
      token".
      
      You could have done that by manually just prefixing the Kerberos token
      with the appropriate bytes, if you weren't going to do any proper SPNEGO
      handling. There's no need for the FBOpenSSL library at all.
      
      The sane way to do SPNEGO is just to *ask* the GSSAPI library to do
      SPNEGO. That's what the 'mech_type' argument to gss_init_sec_context()
      is for. And then it should all Just Work™.
      
      That 'sane way' will be added in a subsequent patch, as will bug fixes
      for our failure to handle any exchange other than a single outbound
      token to the server which results in immediate success.
      9ad282b1
  7. Feb 12, 2014
  8. May 11, 2013
  9. Apr 11, 2013
  10. Apr 09, 2013
  11. Feb 09, 2013
  12. Jan 28, 2013
  13. Nov 08, 2012
  14. Jul 25, 2012
  15. Jul 12, 2012
  16. Jul 11, 2012
  17. Jul 03, 2012
  18. Jun 13, 2012
    • Yang Tse's avatar
      schannel: remove version number and identify its use with 'schannel' literal · 819afe46
      Yang Tse authored
      Version number is removed in order to make this info consistent with
      how we do it with other MS and Linux system libraries for which we don't
      provide this info.
      
      Identifier changed from 'WinSSPI' to 'schannel' given that this is the
      actual provider of the SSL/TLS support. libcurl can still be built with
      SSPI and without SCHANNEL support.
      819afe46
  19. Jun 11, 2012
  20. May 27, 2012
  21. May 22, 2012
  22. Apr 26, 2012
  23. Apr 23, 2012
  24. Apr 22, 2012
  25. Apr 20, 2012
  26. Apr 12, 2012
  27. Dec 30, 2011
  28. Sep 21, 2011
  29. Sep 20, 2011
  30. Sep 11, 2011
  31. Sep 04, 2011
Loading