mupdate TLS

[Andrew Morgan]

On Mon, 16 Jun 2008, Wesley Craig wrote:

> On 16 Jun 2008, at 19:07, Andrew Morgan wrote:
>> Does the mupdate process in a Cyrus murder actually use TLS?
>
> Almost certainly.  mupdate_connect devolves to backend_connect, the same 
> routine that cyrus routinely uses throughout for proxy connections.  Also, 
> the mupdate server pays attention to the "allowplaintext" configuration, so 
> if you're not using TLS and aren't permitting plaintest, passwords don't 
> work.  Are you using GSSAPI?
>
>> The 'mupdatetest' binary doesn't seem to support it.  The --help doesn't
>> list TLS as an option, and if I use "-t ''", it just hangs during TLS
>> negotiation.
>
> I see that imtest / mupdatetest specifically doesn't mention -t wrt mupdate. 
> But imtest's TLS support is pretty broken, AFAIK.  In particular, there's not 
> way at all to set a CA location.  In any case, mupdatetest -t "" does in fact 
> work for me, tho it gives errors about self-signed certificates.  With no CA, 
> self-signed certs are kind of a given.
>
>> It seems like it should work because mupdated lists STARTTLS in the
>> capability string, but none of the hosts in my Cyrus murder try to use TLS
>> as far as I can tell.
>
> If you don't want them to, don't configure certificates for your mupdate 
> master.  Personally, I'm using GSSAPI everywhere, so I prefer not to have 
> certificates configured where they aren't going to provide me with much (if 
> any) benefit.  If you do configure them, they are used.

Following up on this old thread...

When I use mupdatetest with the TLS option, it hangs:

mail1:~# mupdatetest -u cyr_mupdate -a cyr_mupdate -t '' test1.onid.oregonstate.edu
S: * AUTH "PLAIN"
S: * STARTTLS
S: * PARTIAL-UPDATE
S: * OK MUPDATE "test1.onid.oregonstate.edu" "Cyrus Murder" "v2.3.13" "(master)"
C: S01 STARTTLS
S: S01 OK Begin TLS negotiation now
   <long wait here>
SSL_connect error -1
SSL session removed
failure: TLS negotiation failed!


This is what appears in the mupdate server logs:

May 13 13:35:14 test1 mupdate[21064]: accepted connection
May 13 13:35:14 test1 mupdate[21064]: New worker thread started, for a total of 3
May 13 13:38:14 test1 mupdate[21064]: SSL_accept() timed out -> fail
May 13 13:38:14 test1 mupdate[21064]: STARTTLS negotiation failed: mail1.onid.oregonstate.edu [128.193.4.128]
May 13 13:38:14 test1 mupdate[21064]: Connection reset by peer, closing connection
May 13 13:38:14 test1 mupdate[21064]: Thread timed out waiting for listener_lock


I did an strace on mupdatetest and I can see it sending the TLS start 
bits (87 bytes of something).  When I strace the mupdate process on the 
server, I see:

[pid 21098] read(11, "S01 STARTTLS\r\n", 4096) = 14
[pid 21098] write(11, "S01 OK Begin TLS negotiation now"..., 34) = 34
[pid 21098] fcntl64(11, F_GETFL)        = 0x2 (flags O_RDWR)
[pid 21098] fcntl64(11, F_SETFL, O_RDWR|O_NONBLOCK) = 0
[pid 21098] select(1, [], NULL, NULL, {180, 0} <unfinished ...>

The server process doesn't seem to "see" the TLS bits that were sent.


And....  after a lot of digging I see that this is a known bug:

   https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=3119

Never mind!  This sounds like an very complicated problem so I'll just 
stay away from TLS for mupdate.  Although I don't understand why mupdate 
isn't having problems for me right now, since mupdate seems to be 
advertising STARTTLS in the capability string.

 	Andy