Bug 47154 - Auth dialog requested for captive portal certificate
Summary: Auth dialog requested for captive portal certificate
Status: NEW
Alias: None
Product: Telepathy
Classification: Unclassified
Component: gabble (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-09 07:14 UTC by Cosimo Cecchi
Modified: 2013-08-06 13:33 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Cosimo Cecchi 2012-03-09 07:14:30 UTC
[ Using telepathy-gabble-0.15.4 ]

Forwarded from https://bugzilla.gnome.org/show_bug.cgi?id=671660

The wireless network in a coffee shop I went to uses some sort of captive portal to get access.
When the system gets connected to such a network, *before* I log in in the
captive portal, telepathy tries to connect my Google account to the XMPP
server.
Apparently the auth client gets confused though, and I get a lot of dialogs
asking me if I want to accept the certificate, which in this case is coming
*from the captive portal*.

I think there are multiple bugs here:
- I should never get an auth client dialog for a certificate which doesn't come
from the XMPP server itself
- After I dismiss the dialog (with Continue IIRC) I get it again and again
after a bit, since obviously I am not really connected to any public network
and connection keeps failing. It should not retry connection in a row like that
though
- I think ideally I should never ever get an auth dialog like that at all for
GOA accounts (it's OK to get it if I'm connecting to a home/local/LUG server,
but never for Google or Windows Live)
Comment 1 Simon McVittie 2013-08-06 13:33:05 UTC
> - I should never get an auth client dialog for a certificate which doesn't
> come from the XMPP server itself

How would we tell? We're sending TCP to port 443 on Google's server, and getting reply packets that claim to be from Google's server and contain a SSL handshake...

> - After I dismiss the dialog (with Continue IIRC) I get it again and again
> after a bit, since obviously I am not really connected to any public network
> and connection keeps failing.

This could be addressed by making Mission Control not retry if the reason for disconnection is a certificate error. 5.15 might already make this better.

> - I think ideally I should never ever get an auth dialog like that at all for
> GOA accounts (it's OK to get it if I'm connecting to a home/local/LUG server,
> but never for Google or Windows Live)

How would we achieve that? Do you think there should be a "silently reject untrusted certs" flag on "big-name brand" GOA-backed accounts (which empathy-auth would respect), or something?


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.