Шаги по воспроизведению проблемы:
What steps will reproduce the problem?
1. Connect to an XMPP server via TLS. The server has a valid, trusted
certificate, but the certificate has been revoked by its certificate authority.
Каков ожидаемый результат?
What is the expected output?
Psi+ should refuse to connect to the server and display to the user, that the
server's certificate has been revoked.
Что Вы видите вместо этого?
What do you see instead?
Psi+ accepts the certificate without further notice.
Какую версию Psi+ / ОС Вы используете?
What version of the Psi+/OS are you using?
Psi+ 0.16.285 on Debian GNU/Linux
Дополнительная информация по проблеме:
Additional information:
Please implement the Online Certificate Status Protocol (OCSP) in Psi+ to deny
revoked server certificates. Also consider supporting OCSP stapling for
efficiency. A detailed explanation follows:
When Psi+ connects through TLS, it receives the X.509 certificate of the XMPP
server and verifies if it wants to trust this certificate. The certificate
holds a limited range in time for which it is valid. If it is not expired yet
and is signed by a certificate authority, the certificate is trusted if the
certificate is signed by a trusted certificate authority (directly or through
multiple intermediate authorities).
Now there are plenty of reasons why a certificate authority would want to
revoke a certificate before it would expire by itself. Probably the most
serious reason being that the private key associated with the certificate
leaked to the public. The recent Heartbleed bug in OpenSSL allowed attackers
for about two years to acquire the private keys of any TLS based service
running an affected version of OpenSSL, which were estimated by some to be
about one third of the Internet web services. Security researchers and
certificate authorities all around urged people affected by Heartbleed to
revoke all certificates.
Classically certificate authorities regularly issue certificate revokation
lists (CRL). These are signed lists of not-to-be-trusted certificates even
though they appear to be trustworthy on their own. Because CRLs were a pain in
the ass to keep up to date, nowadays certificate authorities offer an OCSP
service. If a certificate is sent to the OCSP service, the service responds
with a signed statement if the certificate is still valid or not. The URL for
the OCSP service is encoded into the issuing certificate authorities
certificate.
When recovering from Heartbleed I noticed that Psi+ seems to neither look up
CRLs nor to use OCSP to check for certificate validity. Psi+ will therefore
trust any certificate that by itself appears to be valid. All of the
certificates affected by Heartbleed and all other certificates which were
willfully revoked by their owners for various other reasons are still trusted
by Psi+.
Imagine now some attacker used Heartbleed to acquire a certificate and the
corresponding private key of an XMPP server. Up to the point where the server
operator replaces the certificate with a new one, the attacker can decrypt
communication between the XMPP and its clients. After the server operator
exchanged the certificate with a new one and revoked the old one, the attacker
could still fool Psi+ clients accepting him as man in the middle who again can
eavesdrop every communication between the XMPP server and client. This is
possible because the Psi+ doesn't realize that the certificate has been revoked
by its owner.
In my opinion this is a big security problem and Psi+ should support OCSP.
The same problem applies to classic Psi and the voice chat tool Mumble which is
also implemented in Qt. I found out that currently Qt's OCSP support is not
production-ready but there is already a good foundation of code provided by
Richard J. Moore. Please see the following Mumble ticket for further
information: https://github.com/mumble-voip/mumble/issues/1231
Original issue reported on code.google.com by a...@raxys.net on 18 Apr 2014 at 11:19
Original issue reported on code.google.com by
a...@raxys.neton 18 Apr 2014 at 11:19