controlling STARTTLS by IP address
On my POP3 server, I need to be able to control the use of STARTTLS by client IP address. Specifically:
- Clients on certain internal subnets (e.g., 192.168.1.0/24) must not have the option to use TLS. If the client tries to use STARTTLS, the option should be rejected. This is to satisfy US FCC rules regarding the use of encryption over certain radio frequencies.
- All other internal clients (e.g., 192.168.0.0/16, but not 192.168.1.0/24) should be able to use STARTTLS if they choose to.
- All external clients (0.0.0.0/0) will be required to use TLS.
Is there a way to control which clients are allowed to use STARTTLS according to the client's IP address?
Thanks, Michael
Sent from my iPhone
On Jul 14, 2016, at 3:56 PM, Michael Fox news@mefox.org wrote:
On my POP3 server, I need to be able to control the use of STARTTLS by client IP address. Specifically:
- Clients on certain internal subnets (e.g., 192.168.1.0/24) must not have the option to use TLS. If the client tries to use STARTTLS, the option should be rejected. This is to satisfy US FCC rules regarding the use of encryption over certain radio frequencies.
- All other internal clients (e.g., 192.168.0.0/16, but not 192.168.1.0/24) should be able to use STARTTLS if they choose to.
- All external clients (0.0.0.0/0) will be required to use TLS.
Is there a way to control which clients are allowed to use STARTTLS according to the client's IP address?
Thanks, Michael
Seems like your firewall could redirect to a different port that doesn't offer starttls.
On 15.07.2016 00:13, Edgar Pettijohn wrote:
Sent from my iPhone
On Jul 14, 2016, at 3:56 PM, Michael Fox news@mefox.org wrote:
On my POP3 server, I need to be able to control the use of STARTTLS by client IP address. Specifically:
- Clients on certain internal subnets (e.g., 192.168.1.0/24) must not have the option to use TLS. If the client tries to use STARTTLS, the option should be rejected. This is to satisfy US FCC rules regarding the use of encryption over certain radio frequencies.
- All other internal clients (e.g., 192.168.0.0/16, but not 192.168.1.0/24) should be able to use STARTTLS if they choose to.
- All external clients (0.0.0.0/0) will be required to use TLS.
Is there a way to control which clients are allowed to use STARTTLS according to the client's IP address?
Thanks, Michael
Seems like your firewall could redirect to a different port that doesn't offer starttls.
You could try
remote x.x.x.x/y { ssl = no }
Aki
You could try
remote x.x.x.x/y { ssl = no }
Aki
Wow. OK. But I can find no documentation on how to use that.
Would it be used inside service pop3-login, or at the top level?
And, does it apply the first match found? For example:
# Disable SSL for radio clients remote 192.168.1.0/24 { ssl = no } # Allow SSL for internal clients remote 192.168.0.0/16 { ssl = yes } # Require SSL for all others remote 0.0.0.0/0 { ssl = required }
Thanks, Michael
On 15.07.2016 00:52, Michael Fox wrote:
You could try
remote x.x.x.x/y { ssl = no }
Aki Wow. OK. But I can find no documentation on how to use that.
Would it be used inside service pop3-login, or at the top level?
And, does it apply the first match found? For example:
# Disable SSL for radio clients remote 192.168.1.0/24 { ssl = no } # Allow SSL for internal clients remote 192.168.0.0/16 { ssl = yes } # Require SSL for all others remote 0.0.0.0/0 { ssl = required }
Thanks, Michael
You can leave the last bit off. Not sure about the ordering, but you'll find out by testing? =)
Aki
Quoting Michael Fox news@mefox.org:
Seems like your firewall could redirect to a different port that doesn't offer starttls.
Yes, of course. But that would require multiple ports, making the client configuration cumbersome and error-prone.
It looks like there's an internal Dovecot solution, so all's well.
I just thought to remind people that with some firewalls, there's always a way to perform "silent" redirections using the DNAT target in the PREROUTING table, i.e.,:
-t nat -A PREROUTING -i ${EXTIF} -s ${NOTLSSOURCES} -p tcp --dport 110
--syn -j DNAT --to-destination ${DOVECOT}:${NOTLSPOP3PORT}
If you're using a Linux iptables firewall, you wouldn't need to expose the different port to the client, but would make use of the NAT subsystem to redirect the connection from certain IP#s->POP3 to the service port where you've denied TLS.
No client would need to be made aware of the "secret" ${NOTLSPOP3PORT}, and in fact, the firewall would continue to DROP packets sent to it from elsewhere if you have a default-deny policy in effect.
=R=
On 16-07-14 16:07:53, M. Balridge wrote:
Quoting Michael Fox news@mefox.org:
Seems like your firewall could redirect to a different port that doesn't offer starttls.
Yes, of course. But that would require multiple ports, making the client configuration cumbersome and error-prone.
It looks like there's an internal Dovecot solution, so all's well.
I just thought to remind people that with some firewalls, there's always a way to perform "silent" redirections using the DNAT target in the PREROUTING table, i.e.,:
-t nat -A PREROUTING -i ${EXTIF} -s ${NOTLSSOURCES} -p tcp --dport 110
--syn -j DNAT --to-destination ${DOVECOT}:${NOTLSPOP3PORT}
That is basically what I meant without enough detail I guess.
If you're using a Linux iptables firewall, you wouldn't need to expose the different port to the client, but would make use of the NAT subsystem to redirect the connection from certain IP#s->POP3 to the service port where you've denied TLS.
No client would need to be made aware of the "secret" ${NOTLSPOP3PORT}, and in fact, the firewall would continue to DROP packets sent to it from elsewhere if you have a default-deny policy in effect.
=R=
-- Edgar Pettijohn
I just thought to remind people that with some firewalls, there's always a way to perform "silent" redirections using the DNAT target in the PREROUTING table, i.e.,:
-t nat -A PREROUTING -i ${EXTIF} -s ${NOTLSSOURCES} -p tcp --dport 110
--syn -j DNAT --to-destination ${DOVECOT}:${NOTLSPOP3PORT}That is basically what I meant without enough detail I guess.
Yes. Good point. And thanks for the clarification.
As a Dovecot newbie, I'm curious. What would be the syntax in dovecot to configure a second pop3 listener? Would it something like this?
service pop3-login { # POP3 for STARTTLS users inet_listener pop3 { port = 110 ssl = yes } # POP3 for no TLS inet_listener pop3 { port = xxx ssl = no } # POP3 for inet_listener pop3s { port = 993 ssl = required }
And shouldn't "inet_listener pop3s" really use ssl=required (as above), instead of ssl=yes (as shown in the default 10-master.conf file)?
Thanks, Michael
On 2016.07.15. 2:07, M. Balridge wrote:
I just thought to remind people that with some firewalls, there's always a way to perform "silent" redirections using the DNAT target in the PREROUTING table, i.e.,:
-t nat -A PREROUTING -i ${EXTIF} -s ${NOTLSSOURCES} -p tcp --dport 110
--syn -j DNAT --to-destination ${DOVECOT}:${NOTLSPOP3PORT}If you're using a Linux iptables firewall, you wouldn't need to expose the different port to the client, but would make use of the NAT subsystem to redirect the connection from certain IP#s->POP3 to the service port where you've denied TLS.
No client would need to be made aware of the "secret" ${NOTLSPOP3PORT}, and in fact, the firewall would continue to DROP packets sent to it from elsewhere if you have a default-deny policy in effect.
=R=
If you're just changing port, better use REDIRECT target.
-- KSb
On 07/14/2016 11:52 PM, Michael Fox wrote:
Seems like your firewall could redirect to a different port that doesn't offer starttls. Yes, of course. But that would require multiple ports, making the client configuration cumbersome and error-prone.
No, the multiple ports would be on the *server* side, and "the firewall" (which could be iptables on the server itself) would DNAT the ever-same *client* side ports based on the clients' IPs.
Speaking of simplifying client configuration: Please note that STARTTLS and "must be plaintext" aren't mutually exclusive:
$ openssl ciphers 'NULL:eNULL:!ECDH:!DH' NULL-SHA256:NULL-SHA:NULL-MD5
https://www.openssl.org/docs/manmaster/apps/ciphers.html#EXAMPLES
If you can get dovecot to use a different "ssl_cipher_list" per client subnet, instead of changing "ssl", you could keep all clients that support those ciphers configured so as to *require* STARTTLS.
Regards,
Jochen Bern Systemingenieur
--
LINworks GmbH
Fon: +49 6151 9067-231 Fax: +49 6151 9067-299 E-Mail: Jochen.Bern@LINworks.de Web: http://www.LINworks.de/
NEC IT Infrastrukturprodukte vom Deutschland Distributor Server, Storage, Virtualisierung, Management Software Shop: http://www.NEC-Store.de/
Briefanschrift: Postfach 10 01 21 · 64201 Darmstadt · DE Hausanschrift: Robert-Koch-Straße 9 · 64331 Weiterstadt · DE Geschäftsführer: Metin Dogan, Nils Manegold, Oliver Michel Unternehmenssitz: Weiterstadt Register: Amtsgericht Darmstadt, HRB 85202
MAX21-Unternehmensgruppe
-----Original Message----- From: dovecot [mailto:dovecot-bounces@dovecot.org] On Behalf Of Jochen Bern Sent: Friday, July 15, 2016 12:46 AM To: dovecot@dovecot.org Subject: Re: RE: controlling STARTTLS by IP address
On 07/14/2016 11:52 PM, Michael Fox wrote:
Seems like your firewall could redirect to a different port that doesn't offer starttls. Yes, of course. But that would require multiple ports, making the client configuration cumbersome and error-prone.
No, the multiple ports would be on the *server* side, and "the firewall" (which could be iptables on the server itself) would DNAT the ever-same *client* side ports based on the clients' IPs.
Speaking of simplifying client configuration: Please note that STARTTLS and "must be plaintext" aren't mutually exclusive:
$ openssl ciphers 'NULL:eNULL:!ECDH:!DH' NULL-SHA256:NULL-SHA:NULL-MD5
https://www.openssl.org/docs/manmaster/apps/ciphers.html#EXAMPLES
If you can get dovecot to use a different "ssl_cipher_list" per client subnet, instead of changing "ssl", you could keep all clients that support those ciphers configured so as to *require* STARTTLS.
Regards,
Jochen Bern Systemingenieur
Hmmm. Interesting. I hadn't thought along those lines. Something to investigate.
Michael
Are you 100% sure your interpretation of the FCC rules is correct? Do you really want passwords going out over RF unencrypted?
As far as I know, only ham bands are not allowed to use encryption. Even baby monitors these days are DECT. (Mind you, not good encryption.)
Original Message From: Michael Fox Sent: Thursday, July 14, 2016 1:57 PM To: Dovecot Mailing List Subject: controlling STARTTLS by IP address
On my POP3 server, I need to be able to control the use of STARTTLS by client IP address. Specifically:
- Clients on certain internal subnets (e.g., 192.168.1.0/24) must not have the option to use TLS. If the client tries to use STARTTLS, the option should be rejected. This is to satisfy US FCC rules regarding the use of encryption over certain radio frequencies.
- All other internal clients (e.g., 192.168.0.0/16, but not 192.168.1.0/24) should be able to use STARTTLS if they choose to.
- All external clients (0.0.0.0/0) will be required to use TLS.
Is there a way to control which clients are allowed to use STARTTLS according to the client's IP address?
Thanks, Michael
Are you 100% sure your interpretation of the FCC rules is correct? Yes
Do you really want passwords going out over RF unencrypted? No. I don't plan to use plaintext auth methods.
As far as I know, only ham bands are not allowed to use encryption. Even baby monitors these days are DECT. (Mind you, not good encryption.) Correct. It is ham radio.
Michael
I'm not a FCC lawyer, just a ham. Seems to me all you could do is "sign" messages and not send them if the sign isn't correct. The package itself is in plain text.
Anyway, I'll leave the thread but would like to hear about the final solution.
Original Message From: Michael Fox Sent: Thursday, July 14, 2016 2:54 PM To: 'Dovecot Mailing List' Subject: RE: controlling STARTTLS by IP address
Are you 100% sure your interpretation of the FCC rules is correct? Yes
Do you really want passwords going out over RF unencrypted? No. I don't plan to use plaintext auth methods.
As far as I know, only ham bands are not allowed to use encryption. Even baby monitors these days are DECT. (Mind you, not good encryption.) Correct. It is ham radio.
Michael
I'm not a FCC lawyer, just a ham. Seems to me all you could do is "sign" messages and not send them if the sign isn't correct. The package itself is in plain text.
I'm not sure what the confusion or concern is. The intention is to use non-plaintext (but technically not encrypted) authentication without TLS over ham frequencies. Hashed challenge/response auth methods don't violate the FCC rules. Of course, without TLS encryption, the auth process is not totally secure. And, yes, the message itself would be in plain text. But it's the best we can do given the rules. Think of it as packet radio on steroids.
73, Michael N6MEF
On 2016.07.15. 11:03, Michael Fox wrote:
I'm not a FCC lawyer, just a ham. Seems to me all you could do is "sign" messages and not send them if the sign isn't correct. The package itself is in plain text.
I'm not sure what the confusion or concern is. The intention is to use non-plaintext (but technically not encrypted) authentication without TLS over ham frequencies. Hashed challenge/response auth methods don't violate the FCC rules. Of course, without TLS encryption, the auth process is not totally secure. And, yes, the message itself would be in plain text. But it's the best we can do given the rules. Think of it as packet radio on steroids.
73, Michael N6MEF
Just curious, it is transferred in some RSxxx serial protocol?
-- KSB
KSB:
Just curious, it is transferred in some RSxxx serial protocol?
The expectation is that the unencrypted traffic will be used for clients on an Ethernet network behind a radio operating on amateur radio frequencies according to FCC Part 97 rules. The radio could be: -- 56+kbps UHF, such as the upcoming UDRX-440 by NW Digital Radio -- WiFi radio using BBHN or AREDN mesh software -- WiFi radio using commercial software, but operated under FCC Part 97 (amateur radio) rules, instead of Part 15 (commercial/consumer) rules -- ... or maybe something else
It won't be the bulk of our traffic, but it is important since it is part of the county's emergency communications plan.
I don't want to hijack this list with amateur radio stuff. Curious hams can contact me off list at n6mef at mefox dot org.
Michael
participants (7)
-
Aki Tuomi
-
Edgar Pettijohn
-
Jochen Bern
-
KSB
-
lists＠lazygranch.com
-
M. Balridge
-
Michael Fox