jest has asked for the wisdom of the Perl Monks concerning the following question:

In a current application, I take any requests for a login page (where passwords might be exchanged) and route them through a secure layer. I handle it in my Apache configuration file, doing something like 

<VirtualHost _default_:80>
  RedirectMatch ^(.*login\.cgi) https://www.mysite.com$1
</VirtualHost>

[download]
Then, in any link coming from the login page, I use an http: prefix to go back to a non-secure page.

This works as far as it goes, but it's rather limited and inflexible for obvious reasons. I'm developing a new application under pure mod_perl, and would like to know if there's a convenient way to do this on the fly, so that, from within a program, I can decide to use the secure sever based on anything I choose--going to a login page, or editing a certain table, or viewing a record that has "price" in it. I wasn't able to find a discussion of this in the mod_perl docs.

Thank you, wise monks.

Replies are listed 'Best First'.
Re: Switching to SSL under mod_perl
by Fletch (Bishop) on Mar 09, 2004 at 15:16 UTC

    Write a PerlTransHandler which decides if the URI matches whatever criteria for needing to be secure and sends back a redirect if it does, or returns DECLINED if it's fine to proceed. Chapter 12 of the mod_perl Developer's Cookbook discusses PerlTransHandlers in detail if you've got that handy, and I'm sure the ORA book does as well (but I don't have that handy and haven't gotten a chance to read it yet so I can't give a more specific pointer).

[reply]
Re: Switching to SSL under mod_perl
by matija (Priest) on Mar 09, 2004 at 15:40 UTC
    I think what you are doing doesn't make much sense.

    Let's break down redirects for two cases:

    GET request
    Carries all the information in the URL. You could redirect this request easily, but there is no point in doing that. Why? Because whoever was sniffing your traffic has already sniffed the data. Transfering the same data again over HTTPS just gives the attacker lots of clear text to try "known plaintext" attacks against your secret key.
    POST request
    POST request does not carry the data in the URL, that data is posted separately, once the connection is established. However, handling of redirected POST requests is extremely browser dependant.
    In addition, if your form is directed to a HTTP address, the people filling out the form won't see the little "safe-data" lock in the corner of their browser window, even thought their data might be safe.

    In short, if you control the forms enough that you could switch them from GET to POST, you control them enough to change the address to https. And if you find a way to implement what you're planing, it won't do you any good.

    Except that you will learn something of mod_perl - that may or may not make it worth it to you.

[reply]

      I'm not sure I follow. If someone heads to a login page, there's no form yet. On their way, they're redirected over a secure link. When they get to the login page, they're on HTTPS. They enter secret information, it goes over HTTPS, and if they're appropriately authenticated, they get sent to some other page over HTTP, and there's no secret information being sent any more.

      It's the same for my other examples--a user tries to visit http://www.mysite.com/edit/secret_table?id=12, they get switched to a secure link before they get there, not after they're entered info.

      Back to mod_perl for a sec--does this have to be handled in a PerlTransHandler, or can I just remap the URL in the regular handler I'm using?

[reply]
        Whether you need mod_perl depends on how you determine if a page needs to be secure or not. If it is simple, like login.cgi and secret_table are always secure, then I would use mod_rewrite. If it is more complex, like secret_table is only protected for id=12, then you need to use mod_perl. I would consider trying to simplyify it so that the need to https is always.

        Also, you might want to consider doing everything with https. This doesn't work on a public login site but makes a lot of sense on an intranet. This has the advantage that you don't have to worry about errors in the access control since everything is encrypted.

[reply]

Back to Seekers of Perl Wisdom