As you will see, this discussion is very much on topic for
a firewalls mailing list.
com (Vik Varma) writes:
>No, it won't necessarily work. The secure web server runs on (normally)
>port 443, not port 80. Port 80 traffic is reserved for non-secure web
>traffic (HTTP, not HTTPS).
This is true (almost). The traffic is encrypted via SSL, but whether or
not the web server is secure web depends on other factors.
>You will need to open up port 443 traffic through your firewall as well
>as port 80, to your web server. Once this is done, you should have full
This is correct.
>PS- I hope you have considered all of the ramifications of allowing web
>traffic inside your firewall.
I would turn the question around. Anybody running an SSL server that is
NOT behind a firewall should carefully consider this situation and ask
himself: Shouldn't the ONLY access to the machine running a secure web
server be through port 443?
If you run it outside a firewall, you are exposing the machine to all
sorts of potential intrusions, thus completely defeating the purpose of
running SSL in the first place. It makes sense to use SSL, which comes
at both performance cost and financial cost, only if the connection
end-points are physically secure. Let me draw you some figures.
A secure SSL-enabled web server:
[ SSL web server ] ------- | ====== The Internet ====
Here the firewall protects the SSL-enabled web server from all
connection attempts except through port 443, and possibly port 80. The
server is physically kept secure. Encrypted data received from the
Internet are decrypted inside a firewall and are hence reasonably
An insecure SSL-enabled web server:
--- | --- [ SSL web server ] ==== The Internet
Here the firewall does not protect the SSL-enabled web server. The
server is subject to all potential intrusion attempts from the global
Internet. The server is no longer physically secure. Encrypted data
received from the Internet are decrypted OUTSIDE THE FIREWALL and are
hence SUBJECT TO INTERCEPTION ATTEMPTS no matter how strong the
encryption is that is use by the SSL protocol.
If you are serious about security, all encryption and decryption must be
done inside the firewall.
The above discussion illustrates that the SSL protocol was poorly
designed. It is not an end-to-end protocol at the topmost application
layer. It runs at a lower layer, and the decryption is done before the
data are passed on to the application. This makes SSL close to useless
for serious security. Any intrusion into the machine running SSL
immediately compromises the transaction.
A properly designed transaction protocol would deliver the data in
still-encrypted form to the final application. Then it won't mattter
whether the web server runs inside a firewall or outside so long as the
final decryption is done inside the firewall. PGP fits the bill, SSL
If you are serious about protecting your data, encrypt it with PGP and
send it so only the final recipient -- not the web server -- can decode
Oh, the other thing to remember about SSL is that in most cases the web
client you use to do the encryption comes to you in poorly documented
binary-only form. You have no idea what it is really doing. If you are
SERIOUS about using the strength provided by 128-bit encryption, you
will use software that you can examine and trust. PGP in source form
fits the bill. Binary-only web browsers emphatically do not.
I sometimes wonder if the folks in the bowels of the NSA giggle with
glee to see how paranoid many people are who insist on 128-bit
encryption, and how silly the same people are to then encrypt their data
using untrusted web clients and decrypt it on web servers running on
machines exposed to the world.
Rahul Dhesi <dhesi @