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
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:
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: [email protected]. 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
Trying 193.219.118.100...
Connected to www.teaparty.net (193.219.118.100).
Escape character is '^]'.
GET /
[...]
<body>
<h1>Bad request!</h1>
<p>
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
Trying 193.219.118.100...
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.
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:
http://l7-filter.sourceforge.net/
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: [email protected]
. The connection will simply be dropped. Try connecting to an HTTPS web server on port 443 and issuing a normal GET request:And that's fairly friendly, as SSL kiss-offs go. Here's a similar experiment with a POP/S server, on port 995:
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.