[Pidgin] #3381: XMPP TLS and (old) SSL man-in-the-middle attack

[Pidgin]

#3381: XMPP TLS and (old) SSL man-in-the-middle attack
-----------------------+----------------------------------------------------
Reporter:  bluefoxicy  |       Owner:  nwalp
    Type:  defect      |      Status:  new  
Priority:  minor       |   Component:  XMPP 
 Version:  2.2.0       |    Keywords:       
 Pending:  0           |  
-----------------------+----------------------------------------------------
 Pidgin's implementation of XMPP TLS and (old) SSL encryption is vulnerable
 to a man-in-the-middle attack.  A malicious user in a hotel or Internet
 café performing ARP spoofing can hijack a new XMPP connection and decrypt
 the data on the fly by replacing the certificate without any alert to the
 end user; a malicious user would need to write a plug-in to Ettercap to
 perform this attack.

 BACKGROUND

 I have a server which was originally called TestIN (Test IntraNet) running
 OpenFire XMPP server.  The TestIN server now resolves as 'jabber' on the
 local network, but uses a self-signed certificate for the domain
 'testin.localnet' that was generated when the server was still ill-named.

 I have tested multiple Jabber/XMPP clients using both the Old SSL (5223)
 encryption and the new TLS encryption.  Viewing the traffic in Wireshark
 shows a short handshake followed by an encrypted session; authentication
 seems to not occur before the encrypted session begins.  This leads me to
 believe the server and client have negotiated encryption properly for any
 given session.

 I noticed with all clients that none of them alert me about the self-
 signed certificate, or about the certificate having a different common
 name than the name used to contact the server.  This non-alert creates the
 security problem described in this issue.

 SPECIFIC PROBLEMS

 The two specific behaviors here that Pidgin must adhere to include
 alerting on a self-signed TLS or SSL certificate, and alerting on a
 certificate for a different common name than the one given for the server.
 If I connect to talk.google.com and get a certificate signed by itself, I
 may be under attack; similarly, I should not connect to talk.google.com
 and be presented with a certificate from www.boguswidgets.com (obtaining a
 CA signed SSL certificate for use in a replacement attack is trivial;
 obtaining it with the name of your target is not).

 RECOMMENDED SOLUTION

 Pidgin should alert the user that the certificate seems to not be
 completely secure on connect, and allow the user to abort before
 authentication (indeed, at the earliest sign of trouble).

 Pidgin should cache the certificate when a user successfully connects to a
 server, either by the certificate being proper or by the user accepting a
 self-signed or incorrect CN certificate.  If the user opts to not be
 alerted anymore for that specific certificate, Pidgin should be quiet
 about it until the certificate changes; else it should inform the user
 each time that the certificate it sees is the same as it was before.

 If a cached certificate changes, Pidgin should alert the user on the
 severity of the change.  If the actual public key does not change, but the
 common name, CA, or self signed status does (i.e. if a self-signed gets CA
 signed), then it should inform the user of this; else it should inform the
 user that the entire certificate has changed.  It can also inform the user
 that a simple self-signed to CA-signed transition makes the certificate
 more trustworthy, as long as the CN of the certificate matches the name of
 the server Pidgen connected to.

-- 
Ticket URL: <http://developer.pidgin.im/ticket/3381>
Pidgin <http://pidgin.im>
Pidgin