Closed Bug 477120 Opened 15 years ago Closed 15 years ago

https cookie headers are stripped.

Categories

(MailNews Core :: Security, defect)

x86
Windows Vista
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 3.0b4

People

(Reporter: bugzilla, Unassigned)

References

Details

(Whiteboard: [fixed by bug 492279])

Attachments

(1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.3 (.NET CLR 3.5.30729)
Build Identifier: 

Thunderbird has this odd habit of stripping cookie headers from https based content. The problem is that it prevents logging into various sites that use https (like feedburner medic feeds and https websites).

Currently, the only way to get around this bug is to create a cookie via firefox and then copy it to Thunderbird. This is very advanced for most users and isn't a desirable option.

Ron, the author of CS Lite, was the one who discovered this issue and shared it with me (with some details). I can supply some more details via my tests, but he would be more knowledgeable on the issue.



Reproducible: Sometimes

Steps to Reproduce:
1. (Optional) Install CS Lite
2. Go to https site (ThunderBrowse) or add a https feed (Feedburner)
3. Prompt to login
4. Login looks like a success, but when you go to access the content, it fails.
Actual Results:  
Cookie headers are not sent

Expected Results:  
Hope to be logged in via cookies from headers.
I suspect we wouldn't block Thunderbird 3 on this if it were the last bug standing, but if you (or anyone else) were interested in putting together a patch, that would be a fine thing.
Flags: wanted-thunderbird3+
My suspicion is that cookie policy wants to be modified so that it behaves differently depending on whether it's in a message or not as well as what kind of message, in a somewhat similar way to the patch in bug 374577.  I expect to post a new version of that patch soon.
Component: General → Security
Product: Thunderbird → MailNews Core
QA Contact: general → security
I agree, the biggest problem here is that afaict the cookie manager in core doesn't extent like the content policy does. It is all in one which I think is why we completely override it - so expect some significant core changes, and any solution would probably help fix bug 431125 - where we have to disable some tests because of our current cookie policy.

Interestingly, it seems what you suggest is what bug 374578 was originally intending on doing ("Only block remote content and cookies for content in the message pane").
Status: UNCONFIRMED → NEW
Ever confirmed: true
Well, the work in bug 374577 is really about looking at the URI of the load and blocking based in that.  It happens to use the docshell to turn off JS only because Gecko doesn't really provide a per document mechanism for that.
I am experiencing the same problems and also plead for them to be tackled. My problem description is there: http://forums.mozillazine.org/viewtopic.php?f=48&t=556097&p=5834985#p5834985. Please read at least four postings from there in order to see what is wrong with ThunderBrowse and HTTPS logins.
(In reply to comment #0)
> 
> Thunderbird has this odd habit of stripping cookie headers from https based
> content. The problem is that it prevents logging into various sites that use
> https (like feedburner medic feeds and https websites).
> 

someone on irc today in the same boat - looking to do bugzilla feed + thunderbrowse
Here's a build for folks to try (see links at bottom), two questions:

1) Does it fix this bug?
2) Does using cookies in RSS feeds still work?

The background:

What I've done is to change TB's cookie policy to be the same used in SeaMonkey (which is a slightly extended version of the Firefox one which includes MailNews additions).

This is essentially the quick and easy, half-hour fix, if it fixes the bug and doesn't regress RSS then we can hopefully (subject to reviews) get this in for TB 3. If it doesn't fix the bug, or regresses RSS then we may not have time to get it in for TB 3.

So please do try and report back. 

Windows and Mac builds available, based on the April 6th source code:

http://s3.mozillamessaging.com/build/try-server/2009-04-06_08:40-bugzilla@standard8.plus.com-st8-cookie1/bugzilla@standard8.plus.com-st8-cookie1-mail-try-win32.installer.exe
http://s3.mozillamessaging.com/build/try-server/2009-04-06_08:40-bugzilla@standard8.plus.com-st8-cookie1/bugzilla@standard8.plus.com-st8-cookie1-mail-try-mac.dmg
(In reply to comment #7)
> Here's a build for folks to try (see links at bottom), two questions:
> 
> 1) Does it fix this bug?
> 2) Does using cookies in RSS feeds still work?
> 
> The background:
> 
> What I've done is to change TB's cookie policy to be the same used in SeaMonkey
> (which is a slightly extended version of the Firefox one which includes
> MailNews additions).
> 
> This is essentially the quick and easy, half-hour fix, if it fixes the bug and
> doesn't regress RSS then we can hopefully (subject to reviews) get this in for
> TB 3. If it doesn't fix the bug, or regresses RSS then we may not have time to
> get it in for TB 3.
> 
> So please do try and report back. 
> 
> Windows and Mac builds available, based on the April 6th source code:
> 
> http://s3.mozillamessaging.com/build/try-server/2009-04-06_08:40-bugzilla@standard8.plus.com-st8-cookie1/bugzilla@standard8.plus.com-st8-cookie1-mail-try-win32.installer.exe
> http://s3.mozillamessaging.com/build/try-server/2009-04-06_08:40-bugzilla@standard8.plus.com-st8-cookie1/bugzilla@standard8.plus.com-st8-cookie1-mail-try-mac.dmg

(In reply to comment #7)
> Here's a build for folks to try (see links at bottom), two questions:
> 
> 1) Does it fix this bug?
> 2) Does using cookies in RSS feeds still work?
> 

Okay, I can confirm it works with my dev build (this is with ThunderBrowse's cookies file disabled [Read the "How to test with ThunderBrowse"]). It looks like it fixes this bug (there are some sites that I now know won't work with ThunderBrowse [that I could have never known before [one being wegame.com]]). I haven't tried an RSS feed yet. But from the current results it looks like it will.

==Site tests==
I can login to several websites that previously were not allowed. Here are the sites that I tested that previously didn't work and their status (all https):

mail.google.com (in fact all of google): PASSED
netvibes.com: PASSED (couldn't login in 2.0.0.19 because it uses https cookies to auth and stalled before)
youtube.com (actually took the google auth cookie): PASSED
twitter.com: PASSED
bugzilla.mozilla.org: PASSED (writing this within ThunderBrowse [however see note])

I'll test more sites soon.

==How to test with ThunderBrowse==
You need to edit two files if you are currently using 3.2.3. tbinit.js and accessbrowser.xul (This bug has been marked for fix in 3.2.4 [using dev build right now])

In accessbrowser.xul delete the line linking to tbcookies.js
In tbinit.js comment lines 133, 327 and 328

Then open about:config and change these prefs:
network.cookie.alwaysAcceptSessionCookies true
network.cookie.disableCookieForMailNews false

Restart your client and you will be able to login successfully.

==bugzilla note==
I don't know if this shows up in fx as well, but I can't post comments on this bug. I get a bugzilla error telling me that the flag status is not valid.
Bugzilla note only applies to ThunderBrowse (I traced the issue down and filed a bug report).
Yesterday I also tested the dev build with the current ThunderBrowse version (fixes as mentioned above not applied). I also succeeded with Google, but failed with e.g. XING (Germany's most popular LinkedIn-like business network) as well as a banking site (dresdner-privat.de). I guess XING uses cookies for auto-login, but the banking site does not, so the latter might be a JavaScript problem rather than a cookie issue (I had also installed the CS Lite add-on). XING also told me that I should activate JS, and the login button does not work. I can only report this from a user point of viw, because I am not an add-on developer.
One more question: If this is a quick-fix and proves to solve the problem reliably, would it be asking too much to port it back to Thunderbird 2? TB3 is not due to be released for quite a while, I suppose.
Thanks for the testing folks, I'll read through the comments later, though the RSS cookie question is still open.

(In reply to comment #11)
> One more question: If this is a quick-fix and proves to solve the problem
> reliably, would it be asking too much to port it back to Thunderbird 2? TB3 is
> not due to be released for quite a while, I suppose.

TB 3 is looking to be around June time, so not that far away. We probably wouldn't back-port as we'd need to do a full study (due to the risks) which I think wouldn't be worth it.
Yes, I noticed XING doesn't work (it acts like it's not submitting but it is [I don't know exactly what is causing it as I've haven't tested enough]). It shows that I have js enabled (maybe I'm missing something [I'm also using the newer 3.2.4 [the one I just uploaded again like 10 seconds ago]]).

Also: paypal.com works fine here. I was able to login okay and manage transfers.

I think this patch fixes the bug just fine but I'll continue to test.
Attached patch Potential base patch (obsolete) — Splinter Review
This is the patch that I put on the try server builds - basically it removes the Thunderbird specific cookie policy and relies on the core policy.

I did take a brief look to see if cookies would work as expected with rss and other things, but ended up getting too confused as to what exactly was going on, and I haven't got time at the moment to take this any further.

To take this patch, I think we'd want to see a set of cases where the cookies were accepted and blocked as we would expect them to be. Preferably these would be automated tests using the http server, or possibly unit tests - there are already some examples about (some of which TB disables due to the current policy set up, see bug 431125).
Blocks: 492279
(In reply to comment #14)
> Created an attachment (id=375169) [details]
> Potential base patch
> 
> This is the patch that I put on the try server builds - basically it removes
> the Thunderbird specific cookie policy and relies on the core policy.
> 
> I did take a brief look to see if cookies would work as expected with rss and
> other things, but ended up getting too confused as to what exactly was going
> on, and I haven't got time at the moment to take this any further.
> 
> To take this patch, I think we'd want to see a set of cases where the cookies
> were accepted and blocked as we would expect them to be. Preferably these would
> be automated tests using the http server, or possibly unit tests - there are
> already some examples about (some of which TB disables due to the current
> policy set up, see bug 431125).

What do you need us/me/whoever to do to get this thing pushed to release?
(In reply to comment #15)
> What do you need us/me/whoever to do to get this thing pushed to release?

I've moved most of this work out to bug 492279 - that bug is now blocking TB 3. I'll document there what I need to do in a few mins.
Attachment #375169 - Attachment is obsolete: true
No longer blocks: 492279
Depends on: 492279
For anyone not following bug 492279 this should be fixed when using Thunderbrowse or looking at content in windows that aren't the main Thunderbird window, i.e. open in new window in Thunderbrowse.

Using cookies when browsing content within the main Thunderbird window will require bug 501925 to be fixed (which we are currently looking at).
Depends on: 501925
I believe Bug 492279 has now fixed this bug. The complete fixes should be in tomorrow's TB 3 nightlies.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: [fixed by bug 492279]
Target Milestone: --- → Thunderbird 3.0b4
(In reply to comment #18)
> I believe Bug 492279 has now fixed this bug. The complete fixes should be in
> tomorrow's TB 3 nightlies.

Awesome. I'm gonna post something on the blog informing my users.
You need to log in before you can comment on or make changes to this bug.