Home / server / Questions / 506634
Accepted
Michael
Asked: 2013-05-11 01:46:47 +0800 CST

How to configure transport CONFIDENTIAL in Apache HTTPD server?

  • 772

We had only one VirtualHost in our Apache 2.2 server configuration:

<VirtualHost _default_:443>

Our customers want be able to put in the browser only the server name in HTTP (e.g. 10.10.0.1) and the sever will redirect automatically to HTTPS. So, we required to add the one addition VirtualHost and to configure redirection to HTTP using RewriteEngine:

<VirtualHost *:80>
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteCond %{REMOTE_HOST} !^127\.0\.0\.1.*$
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</VirtualHost>

Question: Is it possible to configure transport CONFIDENTIAL in Apache HTTPD server? We want to found configuration similar to the following configuration of web.xml:

<transport-guarantee>CONFIDENTIAL</transport-guarantee>

Added

Our requirement: we want be sure for 100 percent that even we opened port 80 for HTTP connection (that allows non encrypted connection) no data can be send or received from port 80. In Java (see the Java definition below) if CONFIDENTIAL is configured and a server configured both encrypted and not encrypted connections (HTTP and HTTPS) only HTTPS is used.

We want to find the similar configuration / Apache module that allow similar configuration.

From http://docs.oracle.com/javaee/5/tutorial/doc/bnbxw.html: Specify CONFIDENTIAL when the application requires that data be transmitted so as to prevent other entities from observing the contents of the transmission.

apache-2.2

2 Answers

  1. Best Answer

    I'm not a great Java expert, but as I understand it, transport-guarantee CONFIDENTIAL means that the data will be encrypted during transit so that nobody else can read it.

    If so, then by redirecting everyone to SSL (which basically means encryption), you've already done that.

    To expand on the above answer:

    Apache configuration is fundamentally different from Java configuration, so you can't always transfer one concept from the other. Unfortunately, this is one of the times that the concept doesn't really translate all that well. Apache will not encrypt traffic on port 80 unless you order it to, which would not be kind to browsers. The thing you can do is to make sure that the only traffic that ever happens on port 80 is one thing and one thing only - whatever the user tries to access, it should be met with a redirect to the SSL site. That means that apache will server no page, no script, no proxied traffic at all whatsoever on port 80. (Except that you're allowing non-encrypted traffic from localhost, which I assume is deliberate.)

    Let me add that I work at a bank. Redirecting port 80 to port 443 is the method we use to force traffic to be encrypted on some of our sites. At no point has that ever allowed non-encrypted traffic through.

    If you want to make assurance double-sure, you could set up an entirely separate apache config directory that listens only on port 80, and have its DocumentRoot set to /var/www/notwanted/, which would itself only contain a web page with a redirect on it. That way you would keep the two entities more separate, with separate log files etc. I don't think it's necessary from a technical standpoint, but it might make administration of the services somewhat easier.

    • 3

  2. Rewrite Engine is superpowerful, but probably overkill for your needs. I would just go with Redirect directive because it's simpler to understand and easier to read.

    <VirtualHost *:80>
    Redirect 301 / https://www.whateverthewebsiteiscalled.com/
</VirtualHost>

    If you really want to use RewriteEngine, you need a bit at the end to turn it into a 301 redirect.

    <VirtualHost *:80>
    RewriteEngine On
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>

    In any case, I don't think you need any of the RewriteConds are adding anything useful. Coming in on port 80 already identifies it as standard HTTP.

    • 1