[Fetchmail-users] sslproto "TLS1" Causes Encrypted Alert Packets.

[Ralph C. <ra...@in...>]

Hi,

I've just added another host and user to my .fetchmailrc.

    poll foo via mail.foo.example proto pop3
    user "ralph@foo.example" is ralph password "letmein"
        ssl sslcertck sslproto "TLS1" sslcommonname "bar.foo.example"

`fetchmail -c foo' successfully establishes a TLS1.2 connection, but
after a flurry of encrypted application data, `Encrypted Alert' packets
are exchanged and the connection closed.  Dropping the -c gives the same
behaviour.  If I keep -c and change "TLS1" to "SSL23" then it doesn't
happen

tshark(1) shows

    client → server  TCP 74        55162 → 995 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=2667494347 TSecr=0 WS=128
    server → client  TCP 74        995 → 55162 [SYN, ACK] Seq=0 Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=1576881705 TSecr=2667494347 WS=128
    client → server  TCP 66        55162 → 995 [ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=2667494357 TSecr=1576881705
    client → server  TLSv1 583     Client Hello
    server → client  TCP 66        995 → 55162 [ACK] Seq=1 Ack=518 Win=30080 Len=0 TSval=1576881772 TSecr=2667494403
    server → client  TLSv1.2 1506  Server Hello
    client → server  TCP 66        55162 → 995 [ACK] Seq=518 Ack=1441 Win=64128 Len=0 TSval=2667494427 TSecr=1576881774
    server → client  TCP 1506      995 → 55162 [ACK] Seq=1441 Ack=518 Win=30080 Len=1440 TSval=1576881774 TSecr=2667494403 [TCP segment of a reassembled PDU]
    client → server  TCP 66        55162 → 995 [ACK] Seq=518 Ack=2881 Win=64128 Len=0 TSval=2667494428 TSecr=1576881774
    server → client  TCP 1506      995 → 55162 [ACK] Seq=2881 Ack=518 Win=30080 Len=1440 TSval=1576881774 TSecr=2667494403 [TCP segment of a reassembled PDU]
    client → server  TCP 66        55162 → 995 [ACK] Seq=518 Ack=4321 Win=64128 Len=0 TSval=2667494430 TSecr=1576881774
    server → client  TLSv1.2 710   Certificate, Server Key Exchange, Server Hello Done
    client → server  TCP 66        55162 → 995 [ACK] Seq=518 Ack=4965 Win=64128 Len=0 TSval=2667494430 TSecr=1576881774
    client → server  TLSv1.2 192   Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
    server → client  TLSv1.2 292   New Session Ticket, Change Cipher Spec, Encrypted Handshake Message
    client → server  TCP 66        55162 → 995 [ACK] Seq=644 Ack=5191 Win=64128 Len=0 TSval=2667494490 TSecr=1576881797
    server → client  TLSv1.2 115   Application Data
    client → server  TCP 66        55162 → 995 [ACK] Seq=644 Ack=5240 Win=64128 Len=0 TSval=2667494501 TSecr=1576881849
    client → server  TLSv1.2 101   Application Data
    server → client  TLSv1.2 184   Application Data
    client → server  TLSv1.2 141   Application Data
    server → client  TLSv1.2 100   Application Data
    client → server  TLSv1.2 114   Application Data
    server → client  TLSv1.2 111   Application Data
    client → server  TLSv1.2 101   Application Data
    server → client  TLSv1.2 104   Application Data
    client → server  TLSv1.2 101   Application Data
    server → client  TLSv1.2 113   Application Data
    server → client  TLSv1.2 97    Encrypted Alert
    client → server  TLSv1.2 97    Encrypted Alert
    client → server  TCP 66        55162 → 995 [RST, ACK] Seq=903 Ack=5554 Win=64128 Len=0 TSval=2667494589 TSecr=1576881935
    server → client  TCP 60        995 → 55162 [RST] Seq=5554 Win=0 Len=0

Using s_client(1), I see the server is Dovecot.

Anyone have ideas as to the cause?

-- 
Cheers, Ralph.