Milko Krachounov | 7 Jan 2010 16:20

This Message is Untrusted

You have asked your mail client to open this email message, but we can't 
confirm that its contents are friendly and polite.

Normally, within a mailing list message, the sender would use kind words to 
prove that he is peaceful and loyal. However, this message contained tons of 
bitter words directed at the addressees, so the good intentions of the sender 
couldn't be verified.

What Should I Do?
If you usually read messages on this mailing list without problems, this error 
could mean that someone just got very angry at you because some of your latest 
moronic decisions, and you shouldn't continue.

[Get me out of here!]

Technical Details
The mailing message contained 89 mild curse words, 17 strong curse words, and 
4 curse words exceeding the threshold of pain.

(Error code: sec_error_too_many_cursewords)

I Understand the Risks
If you understand what's going on, you can tell the mailing system to start 
trusting the sender by performing a short five-minute exorcism. You should do 
this for every message. *Even if you trust the sender, this error could mean 
that he still wants to insult you, attack you, nuke you from orbit or force 
you to listen to Rick Astley.*

Don't do this unless you know for certain that the sender doesn't have a 
reason to come down rudely upon you.
(Continue reading)

alex daloo | 7 Jan 2010 21:03

Fx FTL

Firefox 3.5.7 .... year 2010... mozilla still not able to get ICA
certs... good job mozilla. i told my company the solution (use IE).

just my 2 cents.

good job  <at>  eddy from startcom
Kathleen Wilson | 15 Jan 2010 19:45
Picon
Favicon

Date to disable/remove remaining MD2/MD5 roots from NSS

I have started a discussion in mozilla.dev.security.policy with subject 
“Date to disable/remove remaining MD2/MD5 roots from NSS”.

If this is of interest to you, please refer to and contribute to that 
discussion thread.

Kathleen
Timothy D. Morgan | 26 Jan 2010 21:57
Favicon

Paper: Weaning the Web off of Session Cookies

Hello,

I would like to bring your attention to a paper I published today:
  http://www.vsecurity.com/download/papers/WeaningTheWebOffOfSessionCookies.pdf

It includes a few minor security problems with HTTP authentication
dialog boxes and password managers in several browsers.

More importantly, it makes an argument for a few small changes to
browser behavior and/or standards.  I would hope that Mozilla
developers could take a look and provide any feedback.  I'm
particularly interested in opinions on the suggested 401 response
behavior change.  I have submitted this information to other browser
vendors as well.

thanks!
tim
Daniel Veditz | 27 Jan 2010 17:19

Re: Paper: Weaning the Web off of Session Cookies

On 1/26/10 12:57 PM, Timothy D. Morgan wrote:
> I would like to bring your attention to a paper I published today:
>   http://www.vsecurity.com/download/papers/WeaningTheWebOffOfSessionCookies.pdf
> 
> It includes a few minor security problems with HTTP authentication
> dialog boxes and password managers in several browsers.

This is an area Mozilla has been interested in. You should talk to our
"Mozilla Labs" folks who have been working on Identity in the browser.
They are coming at it from a different angle but there's a lot of
overlap between the problems you and they are trying to solve.

http://www.azarask.in/blog/post/identity-in-the-browser-firefox/
http://mozillalabs.com/blog/2009/05/identity-in-the-browser/

I have a quibble with your section on HTTPOnly cookies. By mentioning
only IE by name when you follow with "other browsers have been slow to
adopt this feature" people will naturally assume that includes Firefox,
the only other browser with significant marketshare. Firefox has
supported HTTPOnly since 2007. Although perhaps "slow" compared to when
Microsoft invented the feature that's pretty irrelevant for a paper
written three years later when nearly all Firefox users will have
support for it.

Continuing that quote with "and continue to have difficulties fully
enforcing this rule in light of newer features (such as AJAX
requests/responses)" people will again assume Firefox, when Firefox was
the first to get this right and in fact IE is one of the browsers with
difficulties. You don't have to take my word for it, this is right in
the OWASP chart linked to from your paper and in the "[16]" link from
(Continue reading)

Timothy D. Morgan | 27 Jan 2010 21:20
Favicon

Re: Paper: Weaning the Web off of Session Cookies

Hi Daniel,

Thanks for taking the time to read through it.

> This is an area Mozilla has been interested in. You should talk to our
> "Mozilla Labs" folks who have been working on Identity in the browser.
> They are coming at it from a different angle but there's a lot of
> overlap between the problems you and they are trying to solve.
> 
> http://www.azarask.in/blog/post/identity-in-the-browser-firefox/
> http://mozillalabs.com/blog/2009/05/identity-in-the-browser/

Cool, there are some great UI ideas there.  I particularly like the
examples that eliminate favicons. ;-)

I would think that moving toward HTTP authentication schemes, such as
digest, would make it much easier to automate a good identity manager.
Would you agree?

> I have a quibble with your section on HTTPOnly cookies. By mentioning
> only IE by name when you follow with "other browsers have been slow to
> adopt this feature" people will naturally assume that includes Firefox,
> the only other browser with significant marketshare. Firefox has
> supported HTTPOnly since 2007. Although perhaps "slow" compared to when
> Microsoft invented the feature that's pretty irrelevant for a paper
> written three years later when nearly all Firefox users will have
> support for it.
>
> Continuing that quote with "and continue to have difficulties fully
> enforcing this rule in light of newer features (such as AJAX
(Continue reading)

Daniel Veditz | 28 Jan 2010 08:47

Re: Paper: Weaning the Web off of Session Cookies

On 1/27/10 12:20 PM, Timothy D. Morgan wrote:
> Cool, there are some great UI ideas there.  I particularly like the
> examples that eliminate favicons. ;-)
> 
> I would think that moving toward HTTP authentication schemes, such as
> digest, would make it much easier to automate a good identity manager.
> Would you agree?

We can't control what web sites do, but if we make the experience nicer
more sites may be encouraged to use things like HTTP Auth. Personally
I'd like to see client certs used for auth but we really have a lot of
work to do to make that a pleasant experience for anyone.

> Another thought I had on performing logouts, which is not presented in
> the paper, is that if the XMLHttpRequest W3C standard is finalized and
> fully adopted by browsers as is, then one might be able to use
> JavaScript to clear credentials

As someone who regularly disables JavaScript I'd hate to see client auth
require it.

>> You must be the Tim who started the "Past proposals for HTTP Auth
>> Logout" thread and if so you're already involved in the right place for
>> that.
> 
> Heh, you did your homework.  Yes, I did start that thread. 

No creepy stalking involved, honest :-) I remembered the topic came up
on the httpbis mailing list recently so I went to see if they had
reached any kind of consensus in the group.
(Continue reading)

Chris Hills | 30 Jan 2010 08:33
Favicon
Gravatar

Re: Paper: Weaning the Web off of Session Cookies

On 28/01/2010 07:47, Daniel Veditz wrote:
> We can't control what web sites do, but if we make the experience nicer
> more sites may be encouraged to use things like HTTP Auth. Personally
> I'd like to see client certs used for auth but we really have a lot of
> work to do to make that a pleasant experience for anyone.

This is why I try to use OpenID where possible, since my provider
supports certificate login, which removes the necessity from the web
site to support it (as long as it supports OpenID of course).
Timothy D. Morgan | 31 Jan 2010 19:12
Favicon

Re: Paper: Weaning the Web off of Session Cookies

> This is why I try to use OpenID where possible, since my provider
> supports certificate login, which removes the necessity from the web
> site to support it (as long as it supports OpenID of course).

That's handy, but doesn't that mean the website you're accessing will
still use cookies once you're authenticated?

tim

Gmane