Re: [Dovecot] Concerned about Dovecot's new NTLM code
I'm pleased to see another project increasing compatibility with windows clients, by the addition of NTLM login support, but I'm a bit worried about a few implementation details, and hope to offer an alternate approach.
I mean no disrespect to those who have implemented to the code so far, but I feel that the idea of 'everybody re-implement NTLM' is prone to failure.
Firstly, to bugs I've noticed by casual inspection of your implementation:
- Unicode support is by 'null padding' - there is no real support for non-ascii characters.
Does it really matter ? Do you know many people who use non-ascii characters in their email addresses and passwords ? :)
- NTLM2 (a negotiated scheme to avoid sending the LM response) is unsupported
Did you RTFS ? Or may be I missed something ?
- NTLMSSP is NDR, not 'C struct pushed to the wire', it needs to be correctly marshaled and unmarshaled.
Yes, it's not a C struct, so what ? Where is the actual bug ?
There are other missing features, some of which are rumoured to become mandatory flags in future, but more importantly, because the implementation is standalone, it has no ability to integrate into an NT/Win2k/Samba domain.
It can be directly integrated with password backends using NTLM password scheme.
As part of the Samba team, I have worked with other projects - Squid in particular, to deliver server-side (and client-side) NTLMSSP authentication, without the need to re-implement the NTLMSSP protocol.
This is done by a callout to 'ntlm_auth', a Samba 3.0 utility designed for this purpose, which in turn can contact domain controllers, allowing for seamless single sign on.
So you'll need Samba to run POP3/IMAP server. Doesn't look convinent to me. Many people have no windows domain infrastructure, but want to provide secure authentication for poor MS Outlook users.
I have recently completed reworking mod_ntlm_winbind for a similar purpose, and have patches for cyrus-sasl in my 'lorikeet' subversion repository. These should serve as good examples for the simple fork()/exec() modal that is used, and also show the support for GSS-SPNEGO (aka HTTP Negotiate) that ntlm_auth also provides.
http://download.samba.org/ftp/unpacked/lorikeet/trunk/
My hope is that I can tempt a Dovecot developer to take on the challenge of modifying the dovecot to use ntlm_auth, and am most willing to answer any questions (here, by private mail or on the samba-technical list) that you may have on the issue.
On Mon, 2004-09-27 at 16:44, Andrey Panin wrote:
I'm pleased to see another project increasing compatibility with windows clients, by the addition of NTLM login support, but I'm a bit worried about a few implementation details, and hope to offer an alternate approach.
I mean no disrespect to those who have implemented to the code so far, but I feel that the idea of 'everybody re-implement NTLM' is prone to failure.
Firstly, to bugs I've noticed by casual inspection of your implementation:
- Unicode support is by 'null padding' - there is no real support for non-ascii characters.
Does it really matter ? Do you know many people who use non-ascii characters in their email addresses and passwords ? :)
A lot, actually. There are serious issues with even simple ASCII/CP850 interactions as it applies to usernames, domains and passwords - that is why Unicode is standard and expected in NTLMSSP. Perhaps more importantly, on the Samba team we have found that matching Microsoft in the move from ASCII to Unicode solved bugs, and avoided untested codepaths on the Microsoft client.
- NTLM2 (a negotiated scheme to avoid sending the LM response) is unsupported
Did you RTFS ? Or may be I missed something ?
I did. This is not NTLMv2, and yes, the naming is confusing. While NTLMv2 is configured, the NTLM2 case is negotiated.
NTLM2 replaces the LM response with a client-supplied challenge, to avoid server-side known plaintext attacks. http://davenport.sourceforge.net/ntlm.html#theNtlm2SessionResponse
- NTLMSSP is NDR, not 'C struct pushed to the wire', it needs to be correctly marshaled and unmarshaled.
Yes, it's not a C struct, so what ? Where is the actual bug ?
In my reading of the code, it appeared not to cope with the multiple forms that NTLMSSP can take, and in particular the Dovecot code seemed to perform some of the conversions by cast.
I'm just a bit worried about some of the parsing code, given the issues that we (the Samba Team) have had in the past. I'm also hoping that this particular nasty can of worms can be kept in one place, where we can implement all the protocol twists and turns, as we come across them.
There are other missing features, some of which are rumoured to become mandatory flags in future, but more importantly, because the implementation is standalone, it has no ability to integrate into an NT/Win2k/Samba domain.
It can be directly integrated with password backends using NTLM password scheme.
I've looked over the source, and I'm having trouble seeing how you are using the Samba passwords (as I can't find a use of the Samba password attributes). The userPassword attribute doesn't exactly count, as Samba never reads nor writes that value directly...
Even if the code was to change to read these attributes, there are two very difficult problems with this. Firstly, I strongly advise against directly relying on the format of the Samba password database - we can and do change that format, as we have done between Samba 2.2 and Samba 3.0, and that presumes LDAP...
This also assumes that the the mail server is privileged to have access to the password-equivalent values in the database, and makes it completely incompatible with a role as a domain member.
(Domain membership allows the IMAP server to be separate from the DC, no matter what it may be running. This allows mail servers to run in a windows or Samba domain, without change to the infrastructure).
This is why I've been working with projects to see how we can best provide Samba's domain membership services beyond just PAM and nss_winbind.
As part of the Samba team, I have worked with other projects - Squid in particular, to deliver server-side (and client-side) NTLMSSP authentication, without the need to re-implement the NTLMSSP protocol.
This is done by a callout to 'ntlm_auth', a Samba 3.0 utility designed for this purpose, which in turn can contact domain controllers, allowing for seamless single sign on.
So you'll need Samba to run POP3/IMAP server. Doesn't look convinent to me. Many people have no windows domain infrastructure, but want to provide secure authentication for poor MS Outlook users.
Unfortunately, without support for NTLM2 at least, the client will send the LM response, which is a particularly weak.
Perhaps we have different aims - but I had hoped that there was some interest in the corporate mail server space, where proper domain integration is critical, and single-sign on (which is what NTLMSSP provides) is expected.
I have enjoyed using Dovecot on my own networks, backed against PAM for authentication. I'm still trying to see how Dovecot's own password database fits into all this however (and why we ended up with one password database per application.. :-)
I'm quite willing to work with developers of independent software packages to see how Samba can be of most assistance. If the issue of 'I need my own password db' is the real sticking point, I'm quite willing to add a callback in ntlm_auth, to fit into such a scheme (I did not propose this intiailly, as otherwise this function is present and working in every Samba 3.0 version).
Thanks,
Andrew Bartlett
-- Andrew Bartlett abartlet@samba.org Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College abartlet@hawkerc.net
Andrew Bartlett wrote:
Perhaps we have different aims - but I had hoped that there was some interest in the corporate mail server space, where proper domain integration is critical, and single-sign on (which is what NTLMSSP provides) is expected.
I, for one, wouldn't mind moving towards single-signon (we are a corporate environment). I hate multiple user databases, and in fact replicate our vpopmail database (which is what Dovecot uses for authentication) out of the internal Netware servers, but it means that e-mail has a different password than the Netware login. I may try to use the eDirectory/PAM support in SuSE Enterprise 9, but I already have to support NTLM in some form internally.
This is a long winded way of saying that I would be interested in seeing the Dovecot code offer more ways of tying into backend authentication sources and I know from personal experience that Samba is an important part of such an effort...
John
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Maybe I'm missing something here, but with LDAP as a backend single sign-on seems to work just fine for Samba (and therefore Windows), email, FTP, you name it. I only have to manage the users in LDAP - no other DB at all.
On Mon, 2004-09-27 at 18:01, John Peacock wrote:
Andrew Bartlett wrote:
Perhaps we have different aims - but I had hoped that there was some interest in the corporate mail server space, where proper domain integration is critical, and single-sign on (which is what NTLMSSP provides) is expected.
I, for one, wouldn't mind moving towards single-signon (we are a corporate environment). I hate multiple user databases, and in fact replicate our vpopmail database (which is what Dovecot uses for authentication) out of the internal Netware servers, but it means that e-mail has a different password than the Netware login. I may try to use the eDirectory/PAM support in SuSE Enterprise 9, but I already have to support NTLM in some form internally.
This is a long winded way of saying that I would be interested in seeing the Dovecot code offer more ways of tying into backend authentication sources and I know from personal experience that Samba is an important part of such an effort...
John
Karl Latiss <karl@designit.com.au> designIT
Karl Latiss wrote:
Maybe I'm missing something here, but with LDAP as a backend single sign-on seems to work just fine for Samba (and therefore Windows), email, FTP, you name it. I only have to manage the users in LDAP - no other DB at all.
Yes, but:
setting up LDAP from scratch is non-trivial;
in a corporate environment, most people are likely to already have an authentication database (which might be Novell, LDAP, Active Directory, NTLM, Kerberos, etc.).
John
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
On Mon, 2004-09-27 at 19:26, Karl Latiss wrote:
Maybe I'm missing something here, but with LDAP as a backend single sign-on seems to work just fine for Samba (and therefore Windows), email, FTP, you name it. I only have to manage the users in LDAP - no other DB at all.
There are issues with what attributes passwords are stored in, access to those passwords and what format they are in.
For example, Samba reads and uses the sambaNTPassword and sambaLMPassword, but OpenLDAP (and other applications) don't use these by default, when authenticating a login. I'm not entirely sure what dovecot wants to use, but it's likewise 'yet another password'. Oh, and I hate 'password sync' issues.
I have solutions I use to avoid all these problems (even Kerberos!), but they are not yet mainstream - what I'm doing here is trying to avoid another application that will 'break' without it's own special password.
Andrew Bartlett
-- Andrew Bartlett abartlet@samba.org Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College abartlet@hawkerc.net
Word on the street is John Peacock said:
This is a long winded way of saying that I would be interested in seeing the Dovecot code offer more ways of tying into backend authentication sources and I know from personal experience that Samba is an important part of such an effort...
Isn't this exactly what PAM is for?
Skye
-- | www.f4.ca | F4 internet | quality web hosting $10/month |
On Wed, 2004-09-29 at 10:24, Skye Poier wrote:
Word on the street is John Peacock said:
This is a long winded way of saying that I would be interested in seeing the Dovecot code offer more ways of tying into backend authentication sources and I know from personal experience that Samba is an important part of such an effort...
Isn't this exactly what PAM is for?
The problem is, despite some apparent initial hopes of the authors, PAM is effectively plaintext only these days, and what this is about is challenge-response NTLMSSP.
Projects like Cyrus-SASL are filling that gap a little, and I have a patch I've submitted to them, for the same thing.
Andrew Bartlett
-- Andrew Bartlett abartlet@samba.org Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College abartlet@hawkerc.net
On 29.9.2004, at 10:19, Andrew Bartlett wrote:
The problem is, despite some apparent initial hopes of the authors, PAM is effectively plaintext only these days, and what this is about is challenge-response NTLMSSP.
Projects like Cyrus-SASL are filling that gap a little, and I have a patch I've submitted to them, for the same thing.
BTW. sometimes after v1.0 I've thought about separating dovecot-auth into separate library so other servers could use it, similiar to Cyrus-SASL library. I'd be interested about getting at least Postfix to use it.
The biggest difference between Cyrus-SASL and Dovecot-SASL is that Cyrus-SASL is simply a library to use, while Dovecot-SASL is client/server making it much easier to use with chrooted/nonprivileged processes (Cyrus' saslauthd is plaintext-only AFAIK).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 29-09-2004 18:00, Timo Sirainen wrote:
| BTW. sometimes after v1.0 I've thought about separating dovecot-auth | into separate library so other servers could use it, similiar to | Cyrus-SASL library. I'd be interested about getting at least Postfix to | use it.
Have you considered also separating the Mailbox access routines?
It would be marvelous if at some point being able to replace c-client library to your optimized one for PHP, mailsync, postman, aolserver and others - even if it means loosing support for odd mailbox formats.
~ - Jonas
- Jonas Smedegaard - idealist og Internet-arkitekt
- Tlf.: +45 40843136 Website: http://dr.jones.dk/
~ - Enden er nær: http://www.shibumi.org/eoti.htm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBWzsvn7DbMsAkQLgRAux5AKCaMvq75V1eH7HcXfVR0It/d1cJmACfY7Nc h8aYY4Owr6fjhp7vYWe0kbo= =pklv -----END PGP SIGNATURE-----
On Mon, 2004-09-27 at 16:44, Andrey Panin wrote:
Firstly, to bugs I've noticed by casual inspection of your implementation:
- Unicode support is by 'null padding' - there is no real support for non-ascii characters.
Does it really matter ? Do you know many people who use non-ascii characters in their email addresses and passwords ? :)
Never encountered a single one outside of LAN's. Anyway correct unicode support is impossible to implement without enormous amount of breakage.
A lot, actually. There are serious issues with even simple ASCII/CP850 interactions as it applies to usernames, domains and passwords - that is why Unicode is standard and expected in NTLMSSP. Perhaps more importantly, on the Samba team we have found that matching Microsoft in the move from ASCII to Unicode solved bugs, and avoided untested codepaths on the Microsoft client.
- NTLM2 (a negotiated scheme to avoid sending the LM response) is unsupported
Did you RTFS ? Or may be I missed something ?
I did. This is not NTLMv2, and yes, the naming is confusing. While NTLMv2 is configured, the NTLM2 case is negotiated.
NTLM2 replaces the LM response with a client-supplied challenge, to avoid server-side known plaintext attacks. http://davenport.sourceforge.net/ntlm.html#theNtlm2SessionResponse
- NTLMSSP is NDR, not 'C struct pushed to the wire', it needs to be correctly marshaled and unmarshaled.
Yes, it's not a C struct, so what ? Where is the actual bug ?
In my reading of the code, it appeared not to cope with the multiple forms that NTLMSSP can take, and in particular the Dovecot code seemed to perform some of the conversions by cast.
I'm just a bit worried about some of the parsing code, given the issues that we (the Samba Team) have had in the past. I'm also hoping that this particular nasty can of worms can be kept in one place, where we can implement all the protocol twists and turns, as we come across them.
There are other missing features, some of which are rumoured to become mandatory flags in future, but more importantly, because the implementation is standalone, it has no ability to integrate into an NT/Win2k/Samba domain.
Domain membership was not a goal, at least until you started this thread.
It can be directly integrated with password backends using NTLM password scheme.
I've looked over the source, and I'm having trouble seeing how you are using the Samba passwords (as I can't find a use of the Samba password attributes). The userPassword attribute doesn't exactly count, as Samba never reads nor writes that value directly...
Even if the code was to change to read these attributes, there are two very difficult problems with this. Firstly, I strongly advise against directly relying on the format of the Samba password database - we can and do change that format, as we have done between Samba 2.2 and Samba 3.0, and that presumes LDAP...
Long time passed after I used samba last time... Do you mean that samba authentication database can contain not only user, but also workstation and other "god knows what" accounts ? IMHO it's a matter of right SQL/LDAP request.
This also assumes that the the mail server is privileged to have access to the password-equivalent values in the database, and makes it completely incompatible with a role as a domain member.
(Domain membership allows the IMAP server to be separate from the DC, no matter what it may be running. This allows mail servers to run in a windows or Samba domain, without change to the infrastructure).
Yes, I heard about domain infrastructure advantages, but not all use it as it's far too complex for many tasks.
As part of the Samba team, I have worked with other projects - Squid in particular, to deliver server-side (and client-side) NTLMSSP authentication, without the need to re-implement the NTLMSSP protocol.
This is done by a callout to 'ntlm_auth', a Samba 3.0 utility designed for this purpose, which in turn can contact domain controllers, allowing for seamless single sign on.
So you'll need Samba to run POP3/IMAP server. Doesn't look convinent to me. Many people have no windows domain infrastructure, but want to provide secure authentication for poor MS Outlook users.
Unfortunately, without support for NTLM2 at least, the client will send the LM response, which is a particularly weak.
NTLMv2 ? On other hand I can't see a way to use non-NTLM (CRAM-MD5,APOP etc) authentication methods with ntlm_auth. Looks like they can't work together and IMHO it's not an interoperability improvement.
Perhaps we have different aims - but I had hoped that there was some interest in the corporate mail server space, where proper domain integration is critical, and single-sign on (which is what NTLMSSP provides) is expected.
Yes, my primary concern is standalone mail servers. It's what I'm payd for after all :)
On Mon, 2004-09-27 at 21:50, Andrey Panin wrote:
On Mon, 2004-09-27 at 16:44, Andrey Panin wrote:
Firstly, to bugs I've noticed by casual inspection of your implementation:
- Unicode support is by 'null padding' - there is no real support for non-ascii characters.
Does it really matter ? Do you know many people who use non-ascii characters in their email addresses and passwords ? :)
Never encountered a single one outside of LAN's. Anyway correct unicode support is impossible to implement without enormous amount of breakage.
That presumes that login name must map to an e-mail address directly, and that no other part of the NTLMSSP packet matters. I'm not sufficiently familiar with Dovecot to comment on the former (exchange, I understand, allows some mapping table between accounts and e-mail addresses, for example), but the use of all ASCII/padded unicode 'because it seems to work' really bothers me, from my Samba experience.
There are other missing features, some of which are rumoured to become mandatory flags in future, but more importantly, because the implementation is standalone, it has no ability to integrate into an NT/Win2k/Samba domain.
Domain membership was not a goal, at least until you started this thread.
That's partly why I started this thread - I've seen support for domain membership hacked into too many other products, usually by adding the really old, really crufty 'smbval' library into the source. If I can avoid it in this product, because I've raised a more viable alternative, I'll by happy.
It can be directly integrated with password backends using NTLM password scheme.
I've looked over the source, and I'm having trouble seeing how you are using the Samba passwords (as I can't find a use of the Samba password attributes). The userPassword attribute doesn't exactly count, as Samba never reads nor writes that value directly...
Even if the code was to change to read these attributes, there are two very difficult problems with this. Firstly, I strongly advise against directly relying on the format of the Samba password database - we can and do change that format, as we have done between Samba 2.2 and Samba 3.0, and that presumes LDAP...
Long time passed after I used samba last time... Do you mean that samba authentication database can contain not only user, but also workstation and other "god knows what" accounts ? IMHO it's a matter of right SQL/LDAP request.
Samba does store much information about a user - and should be consulted by the documented interfaces for user authentication. I specifically advise against directly using the password hash values.
This also assumes that the the mail server is privileged to have access to the password-equivalent values in the database, and makes it completely incompatible with a role as a domain member.
(Domain membership allows the IMAP server to be separate from the DC, no matter what it may be running. This allows mail servers to run in a windows or Samba domain, without change to the infrastructure).
Yes, I heard about domain infrastructure advantages, but not all use it as it's far too complex for many tasks.
I know Samba scares people, and we have tried hard to make it easier to use. Perhaps the biggest problem is that most of the example configurations are just overly complex...
Then again, have you ever tried to set up a kerberos realm? Did you have any hair left - I know how I felt... ;-)
As part of the Samba team, I have worked with other projects - Squid in particular, to deliver server-side (and client-side) NTLMSSP authentication, without the need to re-implement the NTLMSSP protocol.
This is done by a callout to 'ntlm_auth', a Samba 3.0 utility designed for this purpose, which in turn can contact domain controllers, allowing for seamless single sign on.
So you'll need Samba to run POP3/IMAP server. Doesn't look convinent to me. Many people have no windows domain infrastructure, but want to provide secure authentication for poor MS Outlook users.
Unfortunately, without support for NTLM2 at least, the client will send the LM response, which is a particularly weak.
NTLMv2 ?
No, the NTLM2 Session response.
On other hand I can't see a way to use non-NTLM (CRAM-MD5,APOP etc) authentication methods with ntlm_auth. Looks like they can't work together and IMHO it's not an interoperability improvement.
Use of ntlm_auth allows use of external password databases, but doesn't prevent the use of other mechanisms in any way. As I mentioned before, I'm quite willing to work with developers in the implementation of an appropriate callback to allow application that already assume 'I have the plaintext' to have Samba at least handle the NTLMSSP parsing and authentication.
Perhaps we have different aims - but I had hoped that there was some interest in the corporate mail server space, where proper domain integration is critical, and single-sign on (which is what NTLMSSP provides) is expected.
Yes, my primary concern is standalone mail servers. It's what I'm payd for after all :)
Indeed, we all have our focus. :-)
Andrew Bartlett
-- Andrew Bartlett abartlet@samba.org Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College abartlet@hawkerc.net
On 27.9.2004, at 15:17, Andrew Bartlett wrote:
- Unicode support is by 'null padding' - there is no real support for non-ascii characters.
What does support for this actually mean? Does NTLM support multiple character sets or how exactly is the conversion done? A simple UTF8 -> UTF16 would be easy. iconv() could be used for other translations.
Use of ntlm_auth allows use of external password databases, but doesn't prevent the use of other mechanisms in any way. As I mentioned before, I'm quite willing to work with developers in the implementation of an appropriate callback to allow application that already assume 'I have the plaintext' to have Samba at least handle the NTLMSSP parsing and authentication.
I'm not against ntlm_auth() support, but personally I don't really care about it at the moment. I'm of course willing to answer questions about Dovecot code if someone wants to implement it.
On Mon, 2004-09-27 at 22:46, Timo Sirainen wrote:
On 27.9.2004, at 15:17, Andrew Bartlett wrote:
- Unicode support is by 'null padding' - there is no real support for non-ascii characters.
What does support for this actually mean? Does NTLM support multiple character sets or how exactly is the conversion done? A simple UTF8 -> UTF16 would be easy. iconv() could be used for other translations.
So, NTLMSSP can be in ASCII, aka OEM, (as the first packet is, by default) and unicode (UTF16). I've looked over the Dovecot code again, and was a little confused on the first reading. Indeed, the fix to my unicode worries should be just to:
- Support ASCII (for Win9X clients)
- Convert properly between UTF16 and UTF8 when the unicode flag is set.
Use of ntlm_auth allows use of external password databases, but doesn't prevent the use of other mechanisms in any way. As I mentioned before, I'm quite willing to work with developers in the implementation of an appropriate callback to allow application that already assume 'I have the plaintext' to have Samba at least handle the NTLMSSP parsing and authentication.
I'm not against ntlm_auth() support, but personally I don't really care about it at the moment. I'm of course willing to answer questions about Dovecot code if someone wants to implement it.
Why do I feel we are heading for a mexican standoff here ;-)
Andrew Bartlett
-- Andrew Bartlett abartlet@samba.org Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College abartlet@hawkerc.net
On 27.9.2004, at 10:33, Andrew Bartlett wrote:
- NTLMSSP is NDR, not 'C struct pushed to the wire', it needs to be correctly marshaled and unmarshaled.
Yes, it's not a C struct, so what ? Where is the actual bug ?
In my reading of the code, it appeared not to cope with the multiple forms that NTLMSSP can take,
I don't know about that, but
and in particular the Dovecot code seemed to perform some of the conversions by cast.
Where? To me it looks like it uses marshaling/unmarshaling everywhere.
On Mon, 2004-09-27 at 22:49, Timo Sirainen wrote:
On 27.9.2004, at 10:33, Andrew Bartlett wrote:
- NTLMSSP is NDR, not 'C struct pushed to the wire', it needs to be correctly marshaled and unmarshaled.
Yes, it's not a C struct, so what ? Where is the actual bug ?
In my reading of the code, it appeared not to cope with the multiple forms that NTLMSSP can take,
I don't know about that, but
and in particular the Dovecot code seemed to perform some of the conversions by cast.
Where? To me it looks like it uses marshaling/unmarshaling everywhere.
mech-ntlm.c:mech_ntlm_auth_continue()
const struct ntlmssp_request *request =
(struct ntlmssp_request *)data;That's 'unmarshal by cast'...
Andrew Bartlett
-- Andrew Bartlett abartlet@samba.org Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College abartlet@hawkerc.net
On 27.9.2004, at 16:01, Andrew Bartlett wrote:
and in particular the Dovecot code seemed to perform some of the conversions by cast.
Where? To me it looks like it uses marshaling/unmarshaling everywhere.
mech-ntlm.c:mech_ntlm_auth_continue()
const struct ntlmssp_request *request = (struct ntlmssp_request *)data;
Ah, now I understand how that code really works :) Yes, it relies on compiler using specific alignmenting which isn't very good idea. ntlmssp_check_request() should rather be replaced with something like:
static inline uint64_t read_le64(const void **input, uint64_t *output) { *output = *((uint64_t *) *input); *input += sizeof(uint64_t); return *output; }
int ntlm_parse_response(struct ntlmssp_response *response, const void *data, size_t data_size, const char **error_r) { memset(response, 0, sizeof(*response)); .. if (read_le64(&data, &response->magic) != NTLMSSP_MAGIC) { .. if (read_le32(&data, &response->type) != NTLMSSP_MSG_TYPE3) {
participants (7)
-
Andrew Bartlett
-
Andrey Panin
-
John Peacock
-
Jonas Smedegaard
-
Karl Latiss
-
Skye Poier
-
Timo Sirainen