Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Apache: Users

Secure htaccess in a non-SSL Apache (and without Digest...)

 

 

Apache users RSS feed   Index | Next | Previous | View Threaded


daniel.merino at unavarra

Jun 29, 2012, 1:06 AM

Post #1 of 7 (439 views)
Permalink
Secure htaccess in a non-SSL Apache (and without Digest...)

Hi everybody.

We have a really complex issue and we aren't able to imagine how could
it be solved. We hope that maybe some Apache expert will give us some
ideas. Please, if this is not the correct list, tell me where should I
send this email.

We have a Drupal 6 installation which serves video (Flash & HTML5)
working over Apache 2.2.15 in CentOS 6. We want all passwords to be sent
encrypted in this platform.

Configuring a full SSL Apache is not a good solution, because there are
huge videos uploaded and encrypting them would have a great impact in
the performance.

Protecting Drupal's login is quite simple. There is a module that
protects only the login module, so this solution is perfect for us.

However, with some specially sensible videos we also have an extra
protection. We set an htaccess with mod_authn_dbd linked with Drupal
database, so direct access to these resources URLs is protected with the
same user & password used in Drupal.

Is this validation which we are stuck with. If we set AuthType Basic,
passwords are sent in plain text. If we set Digest, it doesn't work
because Digest needs a fixed format (User:Realm:Password in MD5) and
Drupal passwords are different (just password in MD5).

Apache httpd.conf allows to serve some resources through port 80 and
another ones through 443, but the resource to protect must be served
through port 80, so htaccess is also sent through it.

We are really blocked here. Please, could somebody give us any advice?

Many thanks in advance.
--
Daniel Merino Echeverría
daniel.merino [at] unavarra
Gestor de teleformación - Centro Superior de Innovación Educativa.
Tfno: 948-168489 - Universidad Pública de Navarra.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd


alex at alex

Jun 29, 2012, 1:18 AM

Post #2 of 7 (407 views)
Permalink
Re: Secure htaccess in a non-SSL Apache (and without Digest...) [In reply to]

--On 29 June 2012 10:06:04 +0200 Daniel Merino <daniel.merino [at] unavarra>
wrote:

> However, with some specially sensible videos we also have an extra
> protection. We set an htaccess with mod_authn_dbd linked with Drupal
> database, so direct access to these resources URLs is protected with the
> same user & password used in Drupal.

I suggest you don't do that then.

How about getting your http Drupal installation to send out an http URL to
the video which contains e.g. the username, a time, and a hash of both with
a secret.

Then, in the bit serving the videos, check that the hash is valid, and the
time is within (say) 5 seconds of the current time (which will prevent
reuse and token sharing), and just stream with no further authentication.

--
Alex Bligh

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd


daniel.merino at unavarra

Jun 29, 2012, 1:38 AM

Post #3 of 7 (407 views)
Permalink
Re: Secure htaccess in a non-SSL Apache (and withoutDigest...) [In reply to]

Hi, Alex, and thanks for that quick answer.

I'm not sure to understand at all this approach, but anyway, I think
that will not be valid for us.

Drupal's restricted access to the video works fine, but in the moment
that some authorized user can see the video, he can see the video's URL
in the page or in the embed code that we publish for every video.

So if that user pastes the URL in the browser, he has direct access to
the video. Drupal doesn't notice this access and is Apache who must
handle it.

And Apache's protection is sent in plain text unless we serve the video
over SSL.

Regards.

Alex Bligh escribió:
>
>
> --On 29 June 2012 10:06:04 +0200 Daniel Merino
> <daniel.merino [at] unavarra> wrote:
>
>> However, with some specially sensible videos we also have an extra
>> protection. We set an htaccess with mod_authn_dbd linked with Drupal
>> database, so direct access to these resources URLs is protected with the
>> same user & password used in Drupal.
>
> I suggest you don't do that then.
>
> How about getting your http Drupal installation to send out an http
> URL to
> the video which contains e.g. the username, a time, and a hash of both
> with
> a secret.
>
> Then, in the bit serving the videos, check that the hash is valid, and
> the
> time is within (say) 5 seconds of the current time (which will prevent
> reuse and token sharing), and just stream with no further authentication.
>

--
Daniel Merino Echeverría
daniel.merino [at] unavarra
Gestor de teleformación - Centro Superior de Innovación Educativa.
Tfno: 948-168489 - Universidad Pública de Navarra.
--
Beneficiadme con vuestras convicciones, si es que las teneis; pero
guardaros vuestras dudas, pues me bastan las mías. (Goethe)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd


alex at alex

Jun 29, 2012, 2:13 AM

Post #4 of 7 (404 views)
Permalink
Re: Secure htaccess in a non-SSL Apache (and withoutDigest...) [In reply to]

Daniel,

--On 29 June 2012 10:38:24 +0200 Daniel Merino <daniel.merino [at] unavarra>
wrote:

> I'm not sure to understand at all this approach, but anyway, I think that
> will not be valid for us.
>
> Drupal's restricted access to the video works fine, but in the moment
> that some authorized user can see the video, he can see the video's URL
> in the page or in the embed code that we publish for every video.
>
> So if that user pastes the URL in the browser, he has direct access to
> the video. Drupal doesn't notice this access and is Apache who must
> handle it.
>
> And Apache's protection is sent in plain text unless we serve the video
> over SSL.

The answer here really is 'well don't do that then'. Quite apart from
anything else, do you really want credentials (even with digest auth) going
over http at all?

Rather than use http authentication to mediate access to the video, use a
token (that can be in the GET URL, in a cookie, whatever) to prove that the
user is authorised to serve that video, and get Drupal / whatever to check
it. Ensure that access via the 'URL' (meaning the URL without the token)
just does not work. If your token is (e.g.) 256 bits, and linked in the
manner I described to a particular user, video, and time period, then
(a) if it is intercepted, the worst that can happen is someone gets access
to one video for 10 second interval, and (b) no user credentials are passed
in the plain - you can even hide the username. Guessing 256 bit numbers
is not easy.

(re my previous reply, you might want to hash the video name too in
case that was not obvious)

I'm not familiar with Drupal but I am with Wordpress, and you'd just
write a bit of php to do it. If what you are saying is that Apache is just
serving a file, 5 lines of perl and mod_perl can check a GET URL in the
manner I suggested.

If you really want to use custom authentication, you can do that either by
writing your own authentication module (which I've done several times in C)
or use mod_auth_external or similar. However, be warned: you may find the
storage format used is fundamentally incompatible (at an algorithm level
rather than a code level) with digest authentication. You might find it
easier to switch Drupal to using digest authentication too. I have no idea
whether that is possible.

--
Alex Bligh

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd


daniel.merino at unavarra

Jun 29, 2012, 5:04 AM

Post #5 of 7 (400 views)
Permalink
Re: Secure htaccess in a non-SSL Apache (and withoutDigest...) [In reply to]

Hi, Alex.

Having that Apache is serving the file and that we want only to protect
several files placed on a specifical folder, your suggestion of adding
some token to URLs pointing at that folder, and make Apache to deliver
them, seems to be a good solution.

You have talked about perl and mod_perl. I understand that you can
override htaccess to use a self-made bit of Perl code that process it
and check the token. Is this right?

I know very little about Apache programming. Do you have by chance some
code example of these 5 lines of Perl that would check GET_URL?

Thanks in advance.
Regards.

Alex Bligh escribió:
> Daniel,
>
> --On 29 June 2012 10:38:24 +0200 Daniel Merino
> <daniel.merino [at] unavarra> wrote:
>
>> I'm not sure to understand at all this approach, but anyway, I think
>> that
>> will not be valid for us.
>>
>> Drupal's restricted access to the video works fine, but in the moment
>> that some authorized user can see the video, he can see the video's URL
>> in the page or in the embed code that we publish for every video.
>>
>> So if that user pastes the URL in the browser, he has direct access to
>> the video. Drupal doesn't notice this access and is Apache who must
>> handle it.
>>
>> And Apache's protection is sent in plain text unless we serve the video
>> over SSL.
>
> The answer here really is 'well don't do that then'. Quite apart from
> anything else, do you really want credentials (even with digest auth)
> going
> over http at all?
>
> Rather than use http authentication to mediate access to the video, use a
> token (that can be in the GET URL, in a cookie, whatever) to prove
> that the
> user is authorised to serve that video, and get Drupal / whatever to
> check
> it. Ensure that access via the 'URL' (meaning the URL without the token)
> just does not work. If your token is (e.g.) 256 bits, and linked in the
> manner I described to a particular user, video, and time period, then
> (a) if it is intercepted, the worst that can happen is someone gets
> access
> to one video for 10 second interval, and (b) no user credentials are
> passed
> in the plain - you can even hide the username. Guessing 256 bit numbers
> is not easy.
>
> (re my previous reply, you might want to hash the video name too in
> case that was not obvious)
>
> I'm not familiar with Drupal but I am with Wordpress, and you'd just
> write a bit of php to do it. If what you are saying is that Apache is
> just
> serving a file, 5 lines of perl and mod_perl can check a GET URL in the
> manner I suggested.
>
> If you really want to use custom authentication, you can do that
> either by
> writing your own authentication module (which I've done several times
> in C)
> or use mod_auth_external or similar. However, be warned: you may find the
> storage format used is fundamentally incompatible (at an algorithm level
> rather than a code level) with digest authentication. You might find it
> easier to switch Drupal to using digest authentication too. I have no
> idea
> whether that is possible.
>

--
Daniel Merino Echeverría
daniel.merino [at] unavarra
Gestor de teleformación - Centro Superior de Innovación Educativa.
Tfno: 948-168489 - Universidad Pública de Navarra.
--
Nos creíamos que ibamos a cambiar el mundo y casi no podemos cambiar ni
de compañía de móvil. (Forges)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd


alex at alex

Jun 29, 2012, 7:08 AM

Post #6 of 7 (404 views)
Permalink
Re: Secure htaccess in a non-SSL Apache (and withoutDigest...) [In reply to]

Daniel,

--On 29 June 2012 14:04:01 +0200 Daniel Merino <daniel.merino [at] unavarra>
wrote:

> You have talked about perl and mod_perl. I understand that you can
> override htaccess to use a self-made bit of Perl code that process it and
> check the token. Is this right?

You don't need to override htaccess.

Here's a piece of perl found through a random google search to send
a file:
http://rasterweb.net/raster/code/sendfile.html
You'll need to change the header as appropriate. Drop that in as
a CGI script (there are a million examples of perl CGI howtos).
It would be more efficient if it used sendfile.

All you need to do is modify that perl CGI script to check the
GET parameters. My idea was simply to use parameters for your video
name, the time, the user, and perhaps a random nonce, and also pass
a hash of those. So, CGI document is here:
http://perldoc.perl.org/CGI.html
and you might want to do something like (completely untested):

use CGI;
use Digest::SHA qw(sha256_base64 sha256);

my $secret = '[perhaps read this from a file]';

my $video = CGI::url_param('video');
my $user = CGI::url_param('user');
my $time = CGI::url_param('time');
my $nonce = CGI::url_param('nonce');
my $hash = CGI::url_param('hash');

# Sanitize all the above with regexps, i.e. check defined, non-empty

my $checkhash = sha256_base64($video."\n".$user."\n".$time."\n".
$nonce."\n".$secret);
Send404 unless ($checkhash eq $hash);

my $checktime = time();

# Exit unless less than 10 seconds out
Send404 unless (abs($checktime - $time) < 10);

...

# send the file here


When generating the link, you will have to generate the hash in the same
way, and of course a random nonce value.

So anyone can access your CGI program without any protection. However, they
will have to have an appropriate token (being the hash file) to actually
get the video. This has the advantage that if you want to put your video
file servers on EC2 or whatever, or just multiple servers that aren't your
drupal box, it's trivial to do.

--
Alex Bligh

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd


alex at alex

Aug 9, 2012, 1:31 PM

Post #7 of 7 (300 views)
Permalink
Re: Secure htaccess in a non-SSL Apache (and withoutDigest...) [In reply to]

--On 29 June 2012 15:08:44 +0100 Alex Bligh <alex [at] alex> wrote:

>> You have talked about perl and mod_perl. I understand that you can
>> override htaccess to use a self-made bit of Perl code that process it and
>> check the token. Is this right?
>
> You don't need to override htaccess.
>
> Here's a piece of perl found through a random google search to send
> a file:
> http://rasterweb.net/raster/code/sendfile.html
> You'll need to change the header as appropriate. Drop that in as
> a CGI script (there are a million examples of perl CGI howtos).
> It would be more efficient if it used sendfile.
>
> All you need to do is modify that perl CGI script to check the
> GET parameters. My idea was simply to use parameters for your video
> name, the time, the user, and perhaps a random nonce, and also pass
> a hash of those. So, CGI document is here:
> http://perldoc.perl.org/CGI.html
> and you might want to do something like (completely untested):

Well, guess what, I needed to do this myself. So for anyone else
who wants to do it, see:

http://blog.alex.org.uk/2012/08/09/reliable-and-trackable-download-servers/

--
Alex Bligh

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd

Apache users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.