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
----
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
