83134 - Summary of security warnings: redirected POST needs work

Status: RESOLVED WORKSFORME

(Core Graveyard :: Security: UI, defect, P2)

Description

[Terry Hayes]

The current version of the SSL preferences panel is missing several of the items
from the mock-up that we did at the start of the project.  The differences are:

    * "Entering a site that uses low-grade encryption" has been added.
    * "Sending data from a secure page to an insecure page" has been removed.
    * "Redirection from one secure site to another" has been removed
    * "Redirection from a secure site to an insecure site" has been removed

I believe most of these changes are justified.  However, our handling of one
aspect of redirection to an insecure site (POST) should be examined in more
detail.  I'll cover each change below.

1. Entering a site that uses low-grad encryption

This feature was added to allow the user to be notified when a site used SSL
ciphersuites with encryption strengths less than 90 bits.  It controls the
display of the related warning dialog box.

2. Sending data from a secure page to an insecure page

This warning dialog is now always displayed.  There is no preference to change
this behavior, and the warning dialog does not offer to let you change it. 
Therefore the related UI was deleted.

It looks like we were using the same preference for both insecure-to-insecure
and secure-to-insecure posts anyway, so I'm not sure what the mock-up UI  was
controlling.

3. Redirection from one secure site to another

This preference is supposed to allow a warning when one SSL site redirects to
another SSL that is not in the same domain.  Determining whether the new site is
in the same domain has historically been a problem due to the lack of a standard
ruleset to compute this.  Cookie management has also had a similar problem (such
as setting a bigcompany.au cookie from a host called server1.bigcompany.au).

I don't think allowing a site to decide to redirect data from itself to another
SSL-protected site is in the same league of privacy concern as  transferring to
an unsecured site.

PSM2 will continue to allow this transition without warning.  The related
preferences and UI have been removed.

4.  Redirection from a secure site to an insecure site

PSM2 does not currently implement this check. Nelson says there is a function in
the SSL library that can perform the currently defined domain check, but I don't
believe it is being called.  This issue was originally reported in bugzilla bug
35758.  We closed it after discussion at a PDT meeting in May 2000, after
deciding that a secure site might be allowed to make this decision.  This is an
instance of an ongoing debate about what sites should be allowed to do without
warning the user.  Some sites will be incorrectly configured, and might redirect
to an insecure page by mistake.

I believe that incorrect configuration is much less likely to result in this
transition than just a normal link on a page (it takes more work to do a
redirect).  However we might consider dividing this action into two cases: (1)
GET and (2) POST.

The GET case should be handled like a normal transition to an insecure page. xxx

The POST case should probably invoke the normal warning for POST from secure to
insecure, which cannot be turned off.  Unfortunately, the design of the browser
may not allow us to cancel the POST at this stage.  More investigation is
necessary to determine whether this is possible.

In either case (GET or POST) there is no preference that is required to control
the warning.  Therefore deleting the pref and the UI is the right thing.

Comment 1

[Bob Lord]

-> 2.0, P2

Comment 2

[Stephane Saux]

Mass reassigning target to 2.1

Comment 3

[Stephane Saux]

removing nsenterprise keyword from PSM bugs with target milestone of future.

Comment 4

[John Unruh]

Mass assigning QA to ckritzer.

Comment 5

[Kai Engert [:KaiE:]]

This bug is mostly a summary, and the initial comment requests a different
behaviour in its final sentences.

It suggests that when redirecting on the http protocol level between
servers/domains, a warning should be shown and allow the user to cancel.

What we need here is very similar to what is required for bug 62178.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Mass reassign ddrinan's PSM bugs (with his permission) to nobody

Comment 7

[Dana Keeler (she/her) (use needinfo) [:keeler]]

I don't think any of these are relevant any longer.