[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:  wehlhard
      Type:  defect      |      Status:  new     
  Priority:  minor       |   Milestone:          
 Component:  XMPP        |     Version:  2.2.0   
Resolution:              |    Keywords:          
   Pending:  0           |  
-------------------------+--------------------------------------------------
Old description:

> 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.

New description:

 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 Pidgin connected to.

Comment (by rekkanoryo):

 We will NOT be removing the NSS plugin.  GNUTLS isn't an option
 everywhere.

 Patches to implement certificate verification with the NSS plugin are
 welcome.

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