[Pidgin] #9971: Invalid Certificate Chain For Self-Signed Certs

[Pidgin]

#9971: Invalid Certificate Chain For Self-Signed Certs
---------------------------------------------+------------------------------
 Reporter:  rhpt                             |        Owner:  darkrain42
     Type:  defect                           |       Status:  closed    
Milestone:                                   |    Component:  XMPP      
  Version:  2.6.1                            |   Resolution:  duplicate 
 Keywords:  invalid certificate self signed  |  
---------------------------------------------+------------------------------

Comment(by darkrain42):

 Replying to [comment:9 Dymaxion]:
 > So in cases where the administrative contact for a service is not
 available to refresh the certificate, but a service is still providing a
 useful function, users deserve to be annoyed, despite being completely
 aware of the situation?

 I don't think users should be annoyed at all. But users should also be
 wary of using a service where there is no administrator maintaining the
 service.

 >  This seems like an unnecessarily hostile attitude to take toward your
 user base.  Users, not the developers, deserve to be allowed to make the
 choice of whether or not they wish to continue assigning trust to a
 certificate.

 To be honest, I disagree with this ''to an extent''. X.509 and security in
 general are usability disasters.  If most users are presented with a
 dialog that says "Something might be wrong. <possible details here> Do you
 want to continue? [Yes] [No]", they might first select "No". However, when
 (in the case of Pidgin) that fatally terminates that connection, they'll
 restart it and select "Yes", because they '''do''' want to connect to
 Google Talk or AIM or whatever it is. This is compounded by the number of
 things that can be "wrong" with a certificate.

 My personal opinion is that users should be prompted only for
 subjectAlternativeName/CN/hostName mismatches (and even that is a
 compromise). I acknowledge that this can inconvenience more advanced users
 who have a better understanding of X.509 certificates, but I still
 maintain that the correct solution is for server operators to fix their
 certificates.

 >  Ensuring that they're appropriately informed of the situation is quite
 reasonable, but repeatedly doing so is neither useful nor necessary.
 There is a reason that every major browser and almost every other system
 which uses X.509 allows users to make these trust assignments.

 I don't have any experience with ''expired'' certificates in Firefox, but
 I know for a fact that Thunderbird prompts every single time I open the
 program because it was doing that when my mail server was using an old
 certificate (and before you ask, if Thunderbird fatally refused to connect
 to the mail server, it simply would have caused me to stop procrastinating
 on replacing the certificate). Conversely, Apple's Mail.app ''never''
 warned about the exact same certificate, which is wholly unacceptable.

 >  The ability of users to make these assignments in a hassle free manner,
 once informed, does not materially harm the security of their users.

 >  Rather, by making SSL more inconvenient to use, you're actively
 encouraging users not to use it.

 If that is true, it's an unintended side-effect of attempts to get server
 operators to ''fix'' their certificates.

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