Hi Bartosz,

First of all, thank you for volunteering to check this out.

If client trusts a CA which is not universally trusted, is it possible to
find that CA information within the client ? If yes we can use the same CA
to check the certificates, right ?


On Tue, Jun 4, 2013 at 5:07 PM, Bartosz Brachaczek
<b.brachac...@gmail.com>wrote:

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



-- 




Regards,
Radhesh Krishnan K.
_______________________________________________
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel

Reply via email to