576264 - thunderbird start page and other content served over http

Status: RESOLVED FIXED

(Thunderbird :: General, defect)

Description

[chris hofmann]

probably a dup of other bugs but it came up in hack-in-the-box amsterdam conference talk by Laurent Oudot (TEHTRI Security)

http://conference.hackinthebox.org/hitbsecconf2010ams/?page_id=830

he presented a theortical, but reasonable, scenario where tbird users trying to start and get mail on public networks could be vunlerable MiTM attacks where start content at URLs like:

http://live.mozillamessaging.com/thunderbird/start?locale=en-US&version=3.0.4&os=Darwin&buildid=20100317134139

is intercepted and the response replaced with content from evil.com

We probably need to serve this content over https to avoid loosing users to turning this off, or putting them at risk of spoofed content.

Comment 1

[Rafael Ebron (:rebron)]

We can't take a performance hit on these pages.  I made a sad face to chofmann as he explained this to me.

Comment 2

[Philippe M. Chiasson (:gozer)]

That is a valid concern, but both live.momo.com and www.momo.com should be handled over via SSL, since live.momo.com is just a redirection service.

This means 2x SSL requests per page request. Definitely a slowdown for the users, but also a serious amount of extra processing needed on the server-side of things.

Worth noting, the Firefox start page defaults to http:// as well.

Comment 3

[chris hofmann]

(In reply to comment #2)
> Worth noting, the Firefox start page defaults to http:// as well.

yeah that is true.  but I would also argue that the tbird page looks a lot more "chrome-ish",  and there is no indication of what the url actually is.

Comment 4

[Dan Mosedale (:dmosedale, :dmose)]

Agreed that the Tb page seems like a gnarlier phishing target, given that it's less clear where the content is coming from or how it got there.

gozer, I assume it would be a significant amount of work to do the load-balancing with some mechanism (eg inside the DNS server or with an HTTP reverse proxy) that doesn't require two separate HTTP connections?  This would at least avoid generating to separate SSL session keys...

Comment 5

[Philippe M. Chiasson (:gozer)]

(In reply to comment #4)
> Agreed that the Tb page seems like a gnarlier phishing target,

Yes

> given that it's
> less clear where the content is coming from or how it got there.

Not sure what you mean by that... An example maybe ?

> gozer, I assume it would be a significant amount of work to do the
> load-balancing with some mechanism (eg inside the DNS server or with an HTTP
> reverse proxy) that doesn't require two separate HTTP connections?

No, not a lot of work actually. It would somewhat break existing design, however. live.momo.com was designed to be a redirect-only domain that had as its only purpose to be links from the product.

If it turns into a proxy type of thing, certain things become impossible, or very impractical. For instance, if a live url is actually for a domain we don't control, we can't quite proxy it via https and not break relative urls, etc.

> This would at least avoid generating to separate SSL session keys...

True, but in our current setup, that might not be a big cost, since both live.momo.com and www.momo.com use the same cert and the same ssl backends, so I suspect the session keys would be reused (needs checking to be sure)

Comment 6

[Dan Mosedale (:dmosedale, :dmose)]

In Firefox, it's displayed in space that is regularly used to display content that is not part of Firefox itself, and, further, has the URL bar to display the source of that content.  In Thunderbird, it's effectively presented as part of chrome, so people are likely to interpret it as more authoritative.

Indeed, I was speculating that the session keys would be the highest piece of the cost.  Given sufficient time, it would be interesting to actually profile here to understand what and how costs would accrue.

Comment 7

[Mark Banner (:standard8)]

We should work out what we're doing here, and I think that would be best driven by gozer. Therefore re-assigning to him.

Comment 8

[Philippe M. Chiasson (:gozer)]

(In reply to comment #7)
> We should work out what we're doing here, and I think that would be best driven
> by gozer. Therefore re-assigning to him.

Perfectly fine with me. I'd like to try an experiment with this. Mark, how hard would it be to make the nightly builds default preference for live pages to https://live.momo.com while keeping that out of release builds ?

Comment 9

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #5)
> (In reply to comment #4)
> > Agreed that the Tb page seems like a gnarlier phishing target,
> 
> Yes
> 
> > given that it's
> > less clear where the content is coming from or how it got there.
> 
> Not sure what you mean by that... An example maybe ?

There's a bunch of content that happens to be in a box that's being displayed to the user.  Because there are no affordances to suggest that the content is somehow "foreign", I suspect that most users would afford it a higher level of trust than, say, a piece of email, or web page that is presented with a URL bar.

And trying an experiment here sounds like a fine way forward!

Comment 10

[Mark Banner (:standard8)]

(In reply to comment #8)
> (In reply to comment #7)
> > We should work out what we're doing here, and I think that would be best driven
> > by gozer. Therefore re-assigning to him.
> 
> Perfectly fine with me. I'd like to try an experiment with this. Mark, how hard
> would it be to make the nightly builds default preference for live pages to
> https://live.momo.com while keeping that out of release builds ?

I missed this comment previously :-(

gozer: we can very easily do this in nightly builds (and in any new alpha/betas if you want) on all branches. The only thing I see blocking this is that live needs to redirect to the https version of the pages.

Comment 11

[Philippe M. Chiasson (:gozer)]

(In reply to comment #10)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > We should work out what we're doing here, and I think that would be best driven
> > > by gozer. Therefore re-assigning to him.
> > 
> > Perfectly fine with me. I'd like to try an experiment with this. Mark, how hard
> > would it be to make the nightly builds default preference for live pages to
> > https://live.momo.com while keeping that out of release builds ?
> 
> I missed this comment previously :-(
> 
> gozer: we can very easily do this in nightly builds (and in any new alpha/betas
> if you want) on all branches.

Could we start with just nightlies for now, pointing them directly at https://live.momo.com ?

> The only thing I see blocking this is that live
> needs to redirect to the https version of the pages.

Yeah, but that can also easily be done with a small tweaking of the existing rewrite rules. I just need to have them preserve the protocol.

Comment 12

[Mark Banner (:standard8)]

Attachment: Switch nightlies to https - checked in

This will switch the trunk nightly builds to https. If you want to do branch nightlies as well, let me know.

Comment 13

[Philippe M. Chiasson (:gozer)]

Nightly builds will now get served redirects to https://www.momo.com/ from https://live.momo.com/

Comment 14

[Mark Banner (:standard8)]

Comment on attachment 493383 [details] [diff] [review]
Switch nightlies to https - checked in

Checked into comm-central for trunk builds: http://hg.mozilla.org/comm-central/rev/51dbddfa8586

These will start being live from today's builds.

Comment 15

[Mark Banner (:standard8)]

Attachment: Switch 1.9.2 nightlies to https - checked in

This will switch the 1.9.2 nightly builds to https as well. I've done both nightly and unofficial branding there as unofficial is default for the nightly builds, but we may as well do the nightly as well in case developers are building with nightly branding, it doesn't really matter.

Comment 16

[Mark Banner (:standard8)]

Comment on attachment 502374 [details] [diff] [review]
Switch 1.9.2 nightlies to https - checked in

Checked in: http://hg.mozilla.org/releases/comm-1.9.2/rev/a13725d2091e

Comment 17

[Mark Banner (:standard8)]

Attachment: Unofficial & Official branding

This will switch us to https for the Miramar nightlies and preview builds plus for the next major release.

Comment 18

[Mark Banner (:standard8)]

Checked in: http://hg.mozilla.org/comm-central/rev/51c19ec6a4d7

Comment 19

[Mark Banner (:standard8)]

Attachment: Fix 1.9.2 builds - checked in

As 1.9.2 is continuing for now, we should move to https there as well, especially as the load shouldn't be an issue now. This patch does the necessary.

Comment 20

[Mark Banner (:standard8)]

Comment on attachment 558328 [details] [diff] [review]
Fix 1.9.2 builds - checked in

Checked in for 3.1.15: http://hg.mozilla.org/releases/comm-1.9.2/rev/0d2bd6a53177