thunderbird start page and other content served over http

RESOLVED FIXED in Thunderbird 5.0b1

Status

RESOLVED FIXED
9 years ago
7 years ago

People

(Reporter: chofmann, Assigned: standard8)

Tracking

unspecified
Thunderbird 5.0b1
x86
All

Firefox Tracking Flags

(blocking-thunderbird3.1 .15+, thunderbird3.1 .15-fixed, thunderbird3.0 wontfix)

Details

Attachments

(4 attachments)

(Reporter)

Description

9 years ago
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.
(Assignee)

Updated

9 years ago
Assignee: nobody → bugzilla
blocking-thunderbird3.0: --- → .7+
blocking-thunderbird3.1: --- → .2+
We can't take a performance hit on these pages.  I made a sad face to chofmann as he explained this to me.
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.
(Reporter)

Comment 3

9 years ago
(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.
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...
(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)
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.
(Assignee)

Comment 7

9 years ago
We should work out what we're doing here, and I think that would be best driven by gozer. Therefore re-assigning to him.
Assignee: bugzilla → gozer
blocking-thunderbird3.0: .7+ → needed
blocking-thunderbird3.1: .2+ → needed
(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 ?
(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!
(Assignee)

Comment 10

8 years ago
(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.
(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.
(Assignee)

Comment 12

8 years ago
Created attachment 493383 [details] [diff] [review]
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.
Attachment #493383 - Flags: review?(gozer)
Attachment #493383 - Flags: review?(gozer) → review+
Nightly builds will now get served redirects to https://www.momo.com/ from https://live.momo.com/
(Assignee)

Comment 14

8 years ago
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.
Attachment #493383 - Attachment description: Switch nightlies to https → Switch nightlies to https - checked in
(Assignee)

Updated

8 years ago
blocking-thunderbird3.0: needed → ---
status-thunderbird3.0: --- → wontfix
(Assignee)

Comment 15

8 years ago
Created attachment 502374 [details] [diff] [review]
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.
Attachment #502374 - Flags: review?(gozer)
Attachment #502374 - Flags: review?(gozer) → review+
(Assignee)

Comment 16

8 years ago
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
Attachment #502374 - Attachment description: Switch 1.9.2 nightlies to https → Switch 1.9.2 nightlies to https - checked in
(Assignee)

Comment 17

8 years ago
Created attachment 527249 [details] [diff] [review]
Unofficial & Official branding

This will switch us to https for the Miramar nightlies and preview builds plus for the next major release.
Assignee: gozer → bugzilla
Status: NEW → ASSIGNED
Attachment #527249 - Flags: review?(gozer)
Attachment #527249 - Flags: review?(gozer) → review+
(Assignee)

Comment 18

8 years ago
Checked in: http://hg.mozilla.org/comm-central/rev/51c19ec6a4d7
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.3a4
(Assignee)

Comment 19

7 years ago
Created attachment 558328 [details] [diff] [review]
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.
Attachment #558328 - Flags: review?(gozer)
Attachment #558328 - Flags: review?(gozer) → review+
(Assignee)

Updated

7 years ago
Attachment #558328 - Flags: approval-thunderbird3.1.15+
(Assignee)

Comment 20

7 years ago
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
Attachment #558328 - Attachment description: Fix 1.9.2 builds → Fix 1.9.2 builds - checked in
(Assignee)

Updated

7 years ago
blocking-thunderbird3.1: needed → .15+
status-thunderbird3.1: --- → .15-fixed
(Assignee)

Updated

7 years ago
Duplicate of this bug: 611112
You need to log in before you can comment on or make changes to this bug.