Hi,

Simply using SSL_get_verify_result() is not a solution here, as it
returns X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY when connecting
to the proprietary servers on my system (I assume I am not being
attacked, you might want to confirm it yourself).

But checking which certificates are accepted by the proprietary client
should be straightforward, as the current version of it is written in
XUL and uses xulrunner's/gecko's methods of verifying certificates. I
can volunteer to check this. If it turns out that the proprietary
client trusts a CA that is not universally trusted, we might want to
trust the same one when connecting to the Gadu-Gadu network in
libgadu.

Bartosz

PS. I'm attaching a patch so you can easily check what does
SSL_get_verify_result() return on your system.

diff --git a/src/events.c b/src/events.c
index 3f401e9..2cb104c 100644
--- a/src/events.c
+++ b/src/events.c
@@ -1145,6 +1145,10 @@ static gg_action_t
gg_handle_tls_negotiation(struct gg_session *sess, struct gg_

         X509_NAME_oneline(X509_get_issuer_name(peer), buf, sizeof(buf));
         gg_debug_session(sess, GG_DEBUG_MISC, "//   cert issuer: %s\n", buf);
+
+        long res = SSL_get_verify_result(GG_SESSION_OPENSSL(sess));
+        if (res != X509_V_OK)
+            gg_debug_session(sess, GG_DEBUG_MISC, "//   WARNING!
unable to verify peer certificate! res=%ld\n", res);
     }

     sess->state = next_state;


2013/6/4 Radhesh Krishnan K <radheshkrishn...@gmail.com>:
> Hi Wojtek,
>
> Sorry, I have a doubt. I would like to know how certificate validation is
> performed in the proprietary protocol and why something similar cannot be
> performed in this case?
>
>
>
> On Tue, Jun 4, 2013 at 4:41 AM, Wojtek Kaniewski <wojte...@toxygen.net>
> wrote:
>>
>> Dnia 2013-06-02, nie o godzinie 19:02 +0530, Radhesh Krishnan K pisze:
>> > I would like to report a security bug in libgadu.  libgadu is using
>> > openSSL library for creating secure connections.
>> > (...)
>> > So the product using libgadu will be vulnerable to  man-in-the-middle
>> > attack.
>>
>> It was rather a conscious decision. Since libgadu is a
>> reverse-engineered implementation of a proprietary protocol, we have no
>> control over the certificates used for SSL connections. We don't know
>> which certificates will be accepted or rejected by the original client,
>> so there is no reliable way to verify their validity in libgadu. But
>> since you mentioned it, I guess we should at least add a note to the
>> documentation.
>>
>> Regards,
>> Wojtek
>>
>>
>
>
>
> --
>
>
>
>
> Regards,
> Radhesh Krishnan K.
>
> _______________________________________________
> libgadu-devel mailing list
> libgadu-devel@lists.ziew.org
> http://lists.ziew.org/mailman/listinfo/libgadu-devel
>
_______________________________________________
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel

Reply via email to