Re: [Dovecot] Proxying, pertinent values and features, SNI
On 04/04/2013 03:56, Christian Balzer wrote: 2. Despite the fact that it will be trivial for anybody to determine that OEM A is now hosted with us, a SAN SSL makes all the SANs visible in one go, something they probably don't want. But someone smart enough to be able to look at a certificate, is probably also smart enough to be able to go to http://robtex.com and do some reverse IP tests on your IPs... I think the difference is minor - even if you used a whole bunch of IPs, one per customer, if they are near each other, then a few google searches and some use of robtex will quickly show up your customer base Cheers Ed W
Re: [Dovecot] Proxying, pertinent values and features, SNI
On Thu, 4 Apr 2013 22:21:43 +0300 Timo Sirainen wrote:
On 3.4.2013, at 10.59, Christian Balzer ch...@gol.com wrote:
I'm looking into deploying dovecot as a proxy, currently using
perdition. Have been using dovecot on the actual servers for years,
nearly a decade. So far just 1.x, but for the proxy it will have to be
2.x (2.1.7 is the current Debian version), as the trigger for this
change is the need to support multiple SSL certificates.
All that happens on the proxy seems to be handled by the login
processes, so that is why we're not seeing anything useful in the
process titles or with doveadm, right?
And from past comments by Timo I guess that adding such functionality
isn't on his to-do list at all.
doveadm proxy list
That will teach me to look at man pages. ^o^
Internal help all the way, man pages are for chums. ^o^
Thanks!
A configurable capabilities string for POP would be quite welcome, but
at least nothing is different between the 1.x backends and the 2.x
proxy in that protocol.
v2.2 backends actually add some new POP3 capabilities. I guess there
could be such a setting, although it's a bit annoying to develop..
I guess so, but that will really make it an universally deployable proxy
and help people transitioning to dovecot from other environments, too.
[snip]
I presume to best support all(?) clients out there is to have
local_name sections for SNI first and then local sections for IP
address based certs. It is my understanding that SNI needs to be
requested by the client, so aside from client bugs (nah, those don't
exist ^o^) every client should get an appropriate response for TLS.
Has anybody done a setup like that already?
If you have separate IPs for each sertificate, you don't need to
support/configure SNI, so local {} blocks are enough.
I know that, the idea was/is to determine how many (connects and clients)
do a proper TLS/SNI negotiation if offered.
However are these even differently logged by dovecot? I suspect not.
Regards,
Christian
--
Christian BalzerNetwork/Systems Engineer
ch...@gol.com Global OnLine Japan/Fusion Communications
http://www.gol.com/
Re: [Dovecot] Proxying, pertinent values and features, SNI
On 3.4.2013, at 10.59, Christian Balzer ch...@gol.com wrote:
I'm looking into deploying dovecot as a proxy, currently using perdition.
Have been using dovecot on the actual servers for years, nearly a decade.
So far just 1.x, but for the proxy it will have to be 2.x (2.1.7 is the
current Debian version), as the trigger for this change is the need to
support multiple SSL certificates.
All that happens on the proxy seems to be handled by the login processes,
so that is why we're not seeing anything useful in the process titles or
with doveadm, right?
And from past comments by Timo I guess that adding such functionality
isn't on his to-do list at all.
doveadm proxy list
A configurable capabilities string for POP would be quite welcome, but at
least nothing is different between the 1.x backends and the 2.x proxy in
that protocol.
v2.2 backends actually add some new POP3 capabilities. I guess there could be
such a setting, although it's a bit annoying to develop..
Speaking of 1.x versus 2.x, the feature to pass on the remote IP from the
proxy to the backend is a 2.x thing only, correct?
Right.
So I suppose any parameters really affecting this setup are
default_process_limit and default_client_limit as well as the settings
in service-imap-login and service pop-login.
In particular mail_max_userip_connections never is looked at on the proxy
as this check happens in the respective protocol AFTER login, rite?
Right.
I presume to best support all(?) clients out there is to have local_name
sections for SNI first and then local sections for IP address based
certs. It is my understanding that SNI needs to be requested by the
client, so aside from client bugs (nah, those don't exist ^o^) every
client should get an appropriate response for TLS.
Has anybody done a setup like that already?
If you have separate IPs for each sertificate, you don't need to
support/configure SNI, so local {} blocks are enough.
[Dovecot] Proxying, pertinent values and features, SNI
Hello, I'm looking into deploying dovecot as a proxy, currently using perdition. Have been using dovecot on the actual servers for years, nearly a decade. So far just 1.x, but for the proxy it will have to be 2.x (2.1.7 is the current Debian version), as the trigger for this change is the need to support multiple SSL certificates. All that happens on the proxy seems to be handled by the login processes, so that is why we're not seeing anything useful in the process titles or with doveadm, right? And from past comments by Timo I guess that adding such functionality isn't on his to-do list at all. A configurable capabilities string for POP would be quite welcome, but at least nothing is different between the 1.x backends and the 2.x proxy in that protocol. Speaking of 1.x versus 2.x, the feature to pass on the remote IP from the proxy to the backend is a 2.x thing only, correct? So I suppose any parameters really affecting this setup are default_process_limit and default_client_limit as well as the settings in service-imap-login and service pop-login. In particular mail_max_userip_connections never is looked at on the proxy as this check happens in the respective protocol AFTER login, rite? I presume to best support all(?) clients out there is to have local_name sections for SNI first and then local sections for IP address based certs. It is my understanding that SNI needs to be requested by the client, so aside from client bugs (nah, those don't exist ^o^) every client should get an appropriate response for TLS. Has anybody done a setup like that already? Regards, Christian -- Christian BalzerNetwork/Systems Engineer ch...@gol.com Global OnLine Japan/Fusion Communications http://www.gol.com/
Re: [Dovecot] Proxying, pertinent values and features, SNI
Hi I presume to best support all(?) clients out there is to have local_name sections for SNI first and then local sections for IP address based certs. It is my understanding that SNI needs to be requested by the client, so aside from client bugs (nah, those don't exist ^o^) every client should get an appropriate response for TLS. Has anybody done a setup like that already? Although not what you asked for, just so you are aware, Godaddy (boo hiss, etc) offer reasonably inexpensive multi subject alt name based certs. This means you can have a single cert which is valid for lots of completely different domain names. The mild benefit is that this doesn't require SNI support for SSL (which I'm unsure is supported by many mail clients?) Although it's more expensive, I think it's a good solution (I'm using it for a small 5 domain installation) Good luck Ed W
Re: [Dovecot] Proxying, pertinent values and features, SNI
On Wed, 03 Apr 2013 11:13:41 +0100 Ed W wrote: Hi I presume to best support all(?) clients out there is to have local_name sections for SNI first and then local sections for IP address based certs. It is my understanding that SNI needs to be requested by the client, so aside from client bugs (nah, those don't exist ^o^) every client should get an appropriate response for TLS. Has anybody done a setup like that already? Although not what you asked for, just so you are aware, Godaddy (boo hiss, etc) offer reasonably inexpensive multi subject alt name based certs. This means you can have a single cert which is valid for lots of completely different domain names. The mild benefit is that this doesn't require SNI support for SSL (which I'm unsure is supported by many mail clients?) Yeah, I'm aware of multi-domain (SAN) certs, however there are 2 gotchas with those that our support and the OEMs this is for might not approve of: 1. Only the primary host will actually be validated/authenticated, which at least with some browsers will result in this being pointed out to the user when they connect to a SAN. Not sure about mail clients, but webmail is also in that overall deal, so support is probably not going to like the potential concerned you got hacked phone calls from customers. 2. Despite the fact that it will be trivial for anybody to determine that OEM A is now hosted with us, a SAN SSL makes all the SANs visible in one go, something they probably don't want. We're talking a small (10ish) number of OEMs here, so I'm happy and willing to throw some IP addresses at this particular problem and have everybody use (and deal with!) their own certs. As for SNI, supposedly most PC clients will support it, while most mobile ones don't. In my scenario it doesn't matter either way, the idea is to hand the correct cert to a client that requests it via SNI and for all the others based on the IP address they connected to. If everybody can be taught to use only TLS (not IMAPS/POP3S) and all the clients do support SNI, we can do away with the dedicated IP addresses. Might even happen before the heat death of the universe. ^o^ Regards, Christian -- Christian BalzerNetwork/Systems Engineer ch...@gol.com Global OnLine Japan/Fusion Communications http://www.gol.com/
