Re: mod_ssl FakeBasicAuth, the colon problem (PR 52644)
On 06/26/2014 09:22 AM, Ruediger Pluem wrote:
Joe Orton wrote:
I've had a user hit this: with FakeBasicAuth the client DN gets
translated into a Basic auth blob of base64(username:password), which
then fails when the username part contains a : colon character.
At minimum mod_ssl could/should catch and fail auth under FakeBasicAuth
when DN is seen with a :, that's easy enough. We *could* also try
escaping the colon, but that introduces an inevitable ambiguity since
there is no escaping standard.
One approach would be to escape any colon in the DN by replacing with
some unusual character sequence ( or whatever) and then only fail
for unescaped DNs which contain that sequence to avoid ambiguity
problems.
Any opinions before I hack something up?
Probably the correct way to approach this problem is using Graham's
nice hacks in the trunk to allow users to construct an appropriate
username:password blog based on expressions:
http://svn.apache.org/viewvc?view=revisionrevision=r1457471
+1 as this being the real fix at least where the expression parser is available.
Maybe just document the colon problem with FakeBasicAuth and point the user to
AuthBasicFake
to do its own escaping of the colon with the expression parser (at best with an
example).
But I just realize that a simple search and replace function is missing in the
expression parser.
Attached patch implements that. You can test the patch for example like
that:
Require expr replace(%{REQUEST_METHOD}, E, O) == GOT
If there won't be any -1, I will commit it (+ docs) to trunk later this
week.
So maybe hack that up an then go the way above?
Regards
Rüdiger
Regards,
Jan Kaluza
httpd-trunk-ap_expr-replace.patch
Description: application/download
Re: mod_ssl FakeBasicAuth, the colon problem (PR 52644)
Joe Orton wrote: I've had a user hit this: with FakeBasicAuth the client DN gets translated into a Basic auth blob of base64(username:password), which then fails when the username part contains a : colon character. At minimum mod_ssl could/should catch and fail auth under FakeBasicAuth when DN is seen with a :, that's easy enough. We *could* also try escaping the colon, but that introduces an inevitable ambiguity since there is no escaping standard. One approach would be to escape any colon in the DN by replacing with some unusual character sequence ( or whatever) and then only fail for unescaped DNs which contain that sequence to avoid ambiguity problems. Any opinions before I hack something up? Probably the correct way to approach this problem is using Graham's nice hacks in the trunk to allow users to construct an appropriate username:password blog based on expressions: http://svn.apache.org/viewvc?view=revisionrevision=r1457471 +1 as this being the real fix at least where the expression parser is available. Maybe just document the colon problem with FakeBasicAuth and point the user to AuthBasicFake to do its own escaping of the colon with the expression parser (at best with an example). But I just realize that a simple search and replace function is missing in the expression parser. So maybe hack that up an then go the way above? Regards Rüdiger
Re: mod_ssl FakeBasicAuth, the colon problem (PR 52644)
On Thu, Jun 26, 2014 at 9:22 AM, Ruediger Pluem rpl...@apache.org wrote: But I just realize that a simple search and replace function is missing in the expression parser. So maybe hack that up an then go the way above? +1, really nice to have.
mod_ssl FakeBasicAuth, the colon problem (PR 52644)
I've had a user hit this: with FakeBasicAuth the client DN gets translated into a Basic auth blob of base64(username:password), which then fails when the username part contains a : colon character. At minimum mod_ssl could/should catch and fail auth under FakeBasicAuth when DN is seen with a :, that's easy enough. We *could* also try escaping the colon, but that introduces an inevitable ambiguity since there is no escaping standard. One approach would be to escape any colon in the DN by replacing with some unusual character sequence ( or whatever) and then only fail for unescaped DNs which contain that sequence to avoid ambiguity problems. Any opinions before I hack something up? Probably the correct way to approach this problem is using Graham's nice hacks in the trunk to allow users to construct an appropriate username:password blog based on expressions: http://svn.apache.org/viewvc?view=revisionrevision=r1457471 but even that does not actually protect against the colon problem. Regards, Joe
