Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Let's say I want port 12345 open on my box, but I only want to allow a connection through a secure socket (SSL). Is there a flag I can add to the following command:

/sbin/iptables -A INPUT -p tcp --dport 12345 -j ACCEPT


share|improve this question
up vote 2 down vote accepted

I came back to this after thinking for a few days, and realised it's a non-issue. Here's why:

SSL-enabled daemons listen on a port, and expect to negotiate the SSL connection before doing anything else. If you connect and try to do anything other than negotiate SSL, given where you are in the code path, this constitutes an error as surely as does connecting to a web server and typing MAIL FROM: The connection will simply be dropped. Try connecting to an HTTPS web server on port 443 and issuing a normal GET request:

[madhatta@anni tmp]$ telnet www 443
Connected to (
Escape character is '^]'.

<h1>Bad request!</h1>
    Your browser (or proxy) sent a request that
    this server could not understand.

And that's fairly friendly, as SSL kiss-offs go. Here's a similar experiment with a POP/S server, on port 995:

[madhatta@risby video]$ telnet www 995
Connected to www.
Escape character is '^]'.
USER fred
Connection closed by foreign host.

Note, that's a completely lawful POP command; it's just that at that point in the conversation, the daemon requires that I build an SSL connection first, because that's what it's been configured to do. I fed it something that's not SSL, and it dropped me like a leprous potato.

This discussion doesn't apply to TLS, by the way. TLS, an extension of the SSL protocols, explicitly allows a connection to be made in plaintext and then negotiated up to an SSL connection by one end, that end having established that the other end is TLS-capable.

But your question specifically asked about SSL, not TLS, and in any case the solution is simple:

Run a daemon on port 12345 that mandates the use of SSL (ie, isn't TLS-capable) and your job will be done.

share|improve this answer
Thank you for taking the time to experiment and analyze this problem! This is a very informative and useful post! – corsiKa Mar 29 '11 at 16:31
I'm glad you thought so; thank you for your courteous feedback. – MadHatter Mar 29 '11 at 20:40

Nope. Unfortunately iptables only knows about the layer 2/3 stuff: ports, IP protocols, src/destination IP or ethernet addresses, etc.

In order for iptables to know that the TCP stream contains SSL, it would need to analyze the content. It doesn't do that. What you would need is a layer 7 firewall, like the l7-filter project:

share|improve this answer
Insyte: that's not entirely true, since there exist modules like ip_conntrack_ftp which are protocol-aware. If such a module existed for SSL/nonSSL discrimination, iptables could indeed do what the OP asks - but since I don't believe such a module exists, you are right and iptables can't be used to help here. +1 from me, anyway! – MadHatter Mar 16 '11 at 7:32
Would such a filter cause a significant drain on network latency? – corsiKa Mar 16 '11 at 16:34
That depends on the CPU and what you mean by "significant". In the common case, using typical desktop/server CPUs, the answer is "No." – Insyte Mar 17 '11 at 4:06

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.