> 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. Michael
Quoting Michael Fox <news at 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 at 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
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 at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1850 bytes Desc: S/MIME Cryptographic Signature URL: <http://dovecot.org/pipermail/dovecot/attachments/20160715/6c98f98f/attachment-0001.p7s>
> -----Original Message----- > From: dovecot [mailto:dovecot-bounces at dovecot.org] On Behalf Of Jochen > Bern > Sent: Friday, July 15, 2016 12:46 AM > To: dovecot at 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 > SystemingenieurHmmm. Interesting. I hadn't thought along those lines. Something to investigate. Michael