[Forwarded by Marc (CC'ed) to GNOME release-team - Thanks!]

Details from the currently private bug in launchpad.net (see "See Also:" field for the URL) follow:

----

Banshee doesn't appear to do any ssl certificate validation when
accessing https:// links. This has a security impact on the Amazon MP3
Store, the Ubuntu One music store, and possibly more.

This results in a trivial man in the middle attack that can obtain or
alter sensitive information, such as passwords and credit card
information.

Since the original url that is opened by the Amazon MP3 Store and the
Ubuntu One music store is http://, even if banshee were to gain ssl
certificate verification, a MITM could simply alter the https:// link
that is served by the original unencrypted web page.

There is no indication to the user inside the Banshee GUI that a web
page has presented a valid certificate, and no way for the user to
inspect the certificate, so there is no way to prevent a MITM attack.

----

Thank you for the bug report, and for forwarding this.

For the Ubuntu One music store, we just use the widget provided by libubuntuone, and after a quick look at its source code, it doesn't look like it's doing any SSL certificate validation. So you might want to report that issue there too :
https://launchpad.net/libubuntuone

The other integrated web-things (Amazon, eMusic, etc.) are under our control, so we do need to add SSL certificate validation and the corresponding UI.

Created attachment 209440 [details] [review]
Patch to implement and enforce SSL certificate validation

This patch adds SSL certificate validation to our embedded browser.

For now, any page loaded using HTTPS with an invalid or untrusted
certificate will be blocked, and an ugly message will be displayed
instead.
We'll need to improve that user-facing part.

Any review on this is most welcome, particularly on the C code, as I'm not very familiar with that part.

I'm also looking for help with testing, in particular of buying and downloading from Amazon. (I don't have access to an Amazon MP3 store from my country)

(In reply to comment #3)
> Created an attachment (id=209440) [details] [review]
> Patch to implement and enforce SSL certificate validation
> 
> This patch adds SSL certificate validation to our embedded browser.
> 
> For now, any page loaded using HTTPS with an invalid or untrusted
> certificate will be blocked, and an ugly message will be displayed
> instead.
> We'll need to improve that user-facing part.
> 
> Any review on this is most welcome, particularly on the C code, as I'm not very
> familiar with that part.
> 
> I'm also looking for help with testing, in particular of buying and downloading
> from Amazon. (I don't have access to an Amazon MP3 store from my country)

I just tested this patch, but without buying any track just yet.

I'm just wondering, shouldn't we also block with an ugly message (or with a warning at least) if the page loaded is HTTP instead of HTTPS? I know that any site should use HTTPS at least when the user is on the page where he inserts his credit card details, but if we don't really show that this is true, the user cannot be 100% sure that the site is trustable.

I'm thinking that there can be 2 solutions to the above:
1) Show green/red icons depending if page is HTTP or HTTPS (red icon could be an open lock, green could be a closed lock).
2) Show a warning dialog every time an HTTP page is loaded (this could be very annoying for the eMusic store because for normal browsing their HTTPS pages redirect to HTTP, but apparently for Amazon we could default to HTTPS, as it just seems to work.

Thoughts?

The problem is more complex if there is a transition between http and https, as a MITM could simply alter the https link inside the http page to redirect to his own phishing site with a valid ssl certificate.

If there is no way of getting rid of the http completely in the music stores, the user needs to have a way of inspecting the site certificate to see if it's for the right domain, much like he can do in a browser.

For me, https://www.amazon.com sends me back to HTTP. And even if I'm on a page using HTTPS (my account for instance), some links send me back to HTTP. So solution 2 is not good.

Solution 1 is similar to the improvement I was thinking about.
I just think showing a scary red icon might be too much if it's just HTTP, as it might be a normal situation.
I'd like to have a nice, green, reassuring lock icon when it's HTTPS with a valid certificate, and clicking the icon would show the certificate, along with the current URL.

Anyway, I'll trying to improve my patch a bit and commit it in the coming days, as we have a release next week. It's not perfect security-wise, but much better, and we can improve this afterwards.

(In reply to comment #6)
> For me, https://www.amazon.com sends me back to HTTP.

Weird, doesn't happen to me, I guess it's because we're in different countries.

> And even if I'm on a page
> using HTTPS (my account for instance), some links send me back to HTTP. So
> solution 2 is not good.

But do this link belong to non-HTML resources? If yes, we could whitelist them.
(Or maybe it happens to you from your country and not to me.)


> Solution 1 is similar to the improvement I was thinking about.
> I just think showing a scary red icon might be too much if it's just HTTP, as
> it might be a normal situation.

We could show it if the page (a page, not a JS, CSS or an image) is not HTTPS.


> I'd like to have a nice, green, reassuring lock icon when it's HTTPS with a
> valid certificate, and clicking the icon would show the certificate, along with
> the current URL.

We could also prevent the green lock from appearing if the domain in the certificate doesn't match the last page-link loaded?


> Anyway, I'll trying to improve my patch a bit and commit it in the coming days,
> as we have a release next week. It's not perfect security-wise, but much
> better, and we can improve this afterwards.

True.

Comment on attachment 209440 [details] [review]
Patch to implement and enforce SSL certificate validation

I've committed a slightly improved version of that patch, with a better and translatable error message:
http://git.gnome.org/browse/banshee/commit/?id=3e1728264

Any objections on me lifting the visibility restrictions on this bug ?

The partial fix is in git master, and will be included in Banshee 2.4 released on Wednesday 21st.

I'm asking as it includes information about the same issue in libubuntuone, and the launchpad bug is not public yet.

Nope, no objections from me.

Might bug 672537 be an unwanted side effect of this fix?

Well this fix was pushed years ago, so I will close this bug, but the verification is done too late: see bug #747030.