Dear Friends, I have been working on one of the features I want to bring to curl, after the 7.34.0 release, which is really an extension of some of the work I have already performed in 7.34.0.
In 7.34 I added the ability to gracefully cancel an SASL authentication attempt should the client receive bad data from the server for a CRAM-MD5, DIGEST-MD5 and NTLM response rather than simple exiting. If this was to happen, curl will exit with a CURLE_LOGIN_DENIED error after sending the relevant cancellation commands, even though the server may accept multiple mechanisms, such as LOGIN, PLAIN, CRAM-MD5, DIGEST-MD5 and NTLM (others such as GSSAPI are currently unsupported by the email protocols). The next step, which I have already coded up, is for curl to retry lesser mechanisms if the server advertises support for them which means that technically the following could happen: NTLM requested Bad response from server received Client cancels DIGEST-MD5 requested Bad response from server received Client cancels CRAM-MD5 requested Bad response from server received Client cancels LOGIN or PLAIN requested User logged in or access denied However, when I started to write the test harnesses last night I realised there is a possible problem with ftpserver.pl – which I’m not sure how to get around at present. I appreciate that not everyone here will be able to assist with this ☹ All the current IMAP, POP3 and SMTP authentication tests rely on the custom REPLY feature of the test server in order to specify the correct responses. However, the tests I need to add will have two responses each requiring a unique reply by the test server but for the same command (although sent separately by curl). That sounds a little confusing so let's imagine the following SMTP conversation: C: EHLO S: 250-Hello 192.168.0.1 S: 250-SIZE 10485760 S: 250-STARTTLS S: 250-AUTH LOGIN NTLM S: 250 CHUNKING C: AUTH NTLM S: 334 NTLM Accepted C: NTLM <type-1 message> S: 334 Complete and utter rubbish which the client won’t be able to decode C: * S: 501 AUTH cancelled by client C: AUTH LOGIN S: 334 VXNlcm5hbWU6 C: <base-64 encoded username> S: 334 UGFzc3dvcmQ6 C: <base-64 encoded password> S: 235 Authenticated As can be seen with lines 7 and 13, the client sends the AUTH command with the appropriate SASL authentication mechanism. The first time requesting NTLM and the second time requesting LOGIN (after downgrading due to a bad NTLM type-2 response from the server). As such the test server needs to send different responses, but unfortunately, I can’t specify the following in a test case as ftpserver.pl currently stands: <reply> <servercmd> AUTH LOGIN NTLM REPLY AUTH 334 NTLM Accepted REPLY AUTH 334 VXNlcm5hbWU6 </servercmd> </reply> ...as I’m pretty sure the test server will send the second “334 VXNlcm5hbWU6” on both occasions (not 100% about this!) – and whilst this isn’t a problem for NTLM as it only processes the 334 part of the response the server would need to send a challenge for a AUTH CRAM-MD5 request. Anyone have any ideas how we can get round this – I have started to code up support for authentication in ftpserver.pl (but haven't touched that code since August / September time) and isn’t really ready for general consumption as it stands :( Thoughts and ideas are much appreciated. Kind Regards Steve ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
