Re: SSL weakness affecting links from pa

See http://www.Microsoft.com/security/

under "Credit Card Security Concerns and Microsoft's Response"

for Microsoft's response on the SSL GET/POST weakness. ¿Any opinions?

Art Grapa
agrapa@banamex.com

 ----------
From: Mark M.
To: ARTURO GRAPA YSUNZA; Bill Stewart
Cc: cypherpunks@toad.com; cryptography@c2.net
Subject: Re: SSL weakness affecting links from pa
Date: Saturday, March 29, 1997 1:11AM

Microsoft Mail v3.0 IPM.Microsoft Mail.Note
De: Mark M.
Para:  ARTURO GRAPA YSUNZA
     Bill Stewart
Cc:  cypherpunks@toad.com
     cryptography@c2.net
Asunto:  Re: SSL weakness affecting links from pa
Fecha: 1997-03-29 01:11
Prioridad: 3
Ident. del mensaje: 83A07AD005A0D011AF8C006097838CEB

 -----------------------------------------------------------------------
----- --

 -----BEGIN PGP SIGNED MESSAGE-----

On Fri, 28 Mar 1997, Bill Stewart wrote:

> http://www.zdnet.com:80/intweek/daily/970327x.html
> has an article about an SSL problem that affects both Netscape
> and MicrosoftIE browsers, leaking "secure" data such as
> credit card numbers from web pages with GET-based SSL forms on it.
> It was discovered by Dan Klein.
>
> There isn't specific detail about how the flaw works,
> but it says that it affects GET forms but not POST.
> Commentary from NS, MS, Gene Spafford, and Steve Bellovin.
>
>    "It's like you've gone to the restaurant with your lover," Klein said.

>    "The restaurant is there, it's private, yet when you leave the
restaurant
>    you have the menu in your hand and there's food all over your shirt."

I would guess that this means that Netscape and Explorer send the
complete
URL of the page that linked to another site in the "HTTP-REFERER" header
in
the clear when SSL is used.  The only temporary solution is to use a
local
web
proxy that removes this header, or, as the article suggests, manually
type
in
an URL that is linked from a page using SSL.  I can't think of too many
situations where one might follow a link to another site immediately
after
sending sensitive information, but the contents of the "HTTP-REFERER"
header
are often logged, and the log is often world-readable...

>
>
>
> #			Thanks;  Bill
> # Bill Stewart, +1-415-442-2215 stewarts@ix.netcom.com
> # You can get PGP outside the US at ftp.ox.ac.uk/pub/crypto/pgp
> #     (If this is a mailing list, please Cc: me on replies.  Thanks.)
>
>


Mark
 -----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv

iQEVAwUBMzytJyzIPc7jvyFpAQE3gAf/frvfAWg44mEeg2AyhxlFKBmmh3yWEtmq
l8np9nTMz20/PHcF2uzDHrpSEcAY2WPcvEvu+57QGelU0H2LoH2qGFNeVisPQURE
9F5gUZvFeyubL9UVLlUoxVIMCumLM+y31zqVaMb8GwwGnHWNcHc1rqnUhchYamiJ
BbU04U3xaF5b5/mMBzKTU/tfTajeIDsAl0dhk0rzvXAMN2n26idoWic39ZzhHnsE
QOOfi4oI8XK4cMbjOKbwnSR7Xbt78800vilyp+mvkfgp/bR6ygougYzYz1s9dNY3
HgGpnuxDzFoHnqlIQ7in3N+QXXzSNh8TiVfU6w3PjoRk3RNZHX+DTQ==
=QOto
 -----END PGP SIGNATURE-----

At 01:54 AM 4/11/97 -0500, ARTURO GRAPA YSUNZA <agrapa@banamex.com> wrote:
>See http://www.Microsoft.com/security/
>under "Credit Card Security Concerns and Microsoft's Response"
>for Microsoft's response on the SSL GET/POST weakness. ¿Any opinions?

Thanks for the pointer to MS's security site; there's a lot of
good information there.

I was highly unimpressed with Microsoft's Response:
	"It's Not A Security Flaw"
	"But Everybody Important Works Around It"
	"And we're fixing it in the next release"
without providing much detail about what's going on.
It does indicate what to look into to avoid it when writing web pages,
but it doesn't say how to avoid it when entering your credit card number
into a web page, or what to look for as a non-programmer user.


#			Thanks;  Bill
# Bill Stewart, +1-415-442-2215 stewarts@ix.netcom.com
# You can get PGP outside the US at ftp.ox.ac.uk/pub/crypto/pgp
#     (If this is a mailing list, please Cc: me on replies.  Thanks.)

Toto wrote:
> 
> [ long rant deleted ]

I'm just going to reply to what I think it the real substance of your
argument.  If I got the wrong piece, I'm sure you'll tell me.

> Let's get real, here. Corporations add capabilities to their programs
> that allow themselves and other 'major players' to have their way with
> the user.
>   When Joe Average, or a hacker/spammer takes advantage of the same
> capability, then the vendors claim it is a 'bug', or that they can't
> be blamed for the 'bad guys' use of this built-in function.

This particular feature (the HTTP referer header) has nothing to do with
corporations "having their way" with users.  It was created so that web
authors could put "back" buttons on their pages.  The security problem
arises when stupid CGI authors use GET forms to transfer sensitive
information.  This is a security hole in the web site, not in the
browser.  The browser follows the HTTP specification.  If you have a
problem with that, contact the author of that specification.  Or, better
yet, contact the web site (as far as I know, there are none) that has
this security hole.

The only "bad guys" are the web sites that you are giving your private
information to.  If you trust them enough to give them your information
in the first place, shouldn't you trust them not to give it away by
using a GET form?

In the eyes of some, the referer header is a privacy violation.  It
allows a site to see what site you visited before coming there.  In the
case of Navigator, we ONLY send the referer header when you click on a
link.  Not when you select a bookmark.  Not when you type a URL into the
location field.  This allows web sites to see who links to them.  I
think that's something that a web author is entitled to know.

So, you think we're doing something bad.  Why don't you tell me what
you think we should do?

-- 
You should only break rules of style if you can    | Tom Weinstein
coherently explain what you gain by so doing.      | tomw@netscape.com

On Mon, 14 Apr 1997, Tom Weinstein wrote:

> In the eyes of some, the referer header is a privacy violation.  It
> allows a site to see what site you visited before coming there.  In the
> case of Navigator, we ONLY send the referer header when you click on a
> link.  Not when you select a bookmark.  Not when you type a URL into the
> location field.  This allows web sites to see who links to them.  I
> think that's something that a web author is entitled to know.
> 
> So, you think we're doing something bad.  Why don't you tell me what
> you think we should do?

Thanks for the chance to address the issue.

I think that perfectly reasonable "features" often can become "security
flaws" or "privacy lapses" when the user is not aware of the potential
danger.  In this case I think much of the flak over the referer header is
driven by the fact that no one really appreciated the danger until it was
pointed out.  This gives rise to the "My god!  What have I been giving out
all these months while accessing www.hotchicks.com?" panic.  Of course
the next step is anger.  "Why the hell does <netscape> do that?  Why
wasn't I told?"

This melds into another software annoyance of mine.  Sacrificing the needs
of the user who knows what he is doing for the novice when both can be
easily satisified.  Of course the reverse is also true.  Take, for
example, Mr. Stewart's comment:

>I basically agree with Microsoft.  It works as specified, and everyone
>should know that handling sensitive form posts via GET is a bad idea.

Well, those of us who know what we are doing should know better but (and
I'm not sure this is Mr. Weinstein's mission or concern) if you want to
educate the public you need to assume the user does not know and create
and option to streamline operation for the user who does.

Having said the above, what I would like to see is an option to surpress
the referer header explicitly like with cookies.

"You are about to forward a referer header to the page you have selected.
Forwarding the referer header to this site may reveal more about your web
browsing habits than you would prefer.  Should <netscape> surpress the
referer header?  Yes/No/Always Surpress/Never Surpress."

I might add that I would like an option on cookie supression to bypass
that annoying dialog such to never allow cookies.  It gets a bit much when
a page askes for 9 cookies in a row and the only way to prevent them is to
get beeped at repeatedly.  Again, don't confuse the novice, don't slow
down the expert.

> -- 
> You should only break rules of style if you can    | Tom Weinstein
> coherently explain what you gain by so doing.      | tomw@netscape.com

--
Forward complaints to : European Association of Envelope Manufactures
Finger for Public Key   Gutenbergstrasse 21;Postfach;CH-3001;Bern
Vote Monarchist         Switzerland

Black Unicorn writes:
 
> I might add that I would like an option on cookie supression to bypass
> that annoying dialog such to never allow cookies.  It gets a bit much when
> a page askes for 9 cookies in a row and the only way to prevent them is to
> get beeped at repeatedly.  Again, don't confuse the novice, don't slow
> down the expert.

RFC 2109, released a couple months ago, addresses this.  Unless
Doubleclick is successful in getting it changed. :-(

I don't think any browsers yet support the cookie-choice features of 2109
(correct me if I'm wrong).  So in the mean time you can use Cookie Jar
(http://www.lne.com/ericm/cookie_jar/) to filter out cookies and
Referer: tags and ads.



-- 
   Eric Murray  ericm@lne.com         Privacy through technology!
  Network security and encryption consulting.    PGP keyid:E03F65E5

A million monkeys operating under the pseudonym 
 "Black Unicorn <unicorn@schloss.li>" typed:
>
> "You are about to forward a referer header to the page you have selected.
> Forwarding the referer header to this site may reveal more about your web
> browsing habits than you would prefer.  Should <netscape> surpress the
> referer header?  Yes/No/Always Surpress/Never Surpress."


Minor UI nit:  it would be much much better if it said 


"You are about to send a 'referrer header' telling the next web 
site about the web page you are currently looking at.  Should 
<netscape> send this 'referrer header'?  
[Yes/No/Always Send Referrer Headers/Never Send Referrer Headers]"



Regards,

Zooko Journeyman

Disclaimers follow:  I am not a cypherpunk.  NOT speaking for 
DigiCash or any other person or organization.  No PGP sig follows.

> This particular feature (the HTTP referer header) has nothing to do with
> corporations "having their way" with users.  It was created so that web
> authors could put "back" buttons on their pages.  The security problem
> arises when stupid CGI authors use GET forms to transfer sensitive
> information.  This is a security hole in the web site, not in the
> browser.  The browser follows the HTTP specification.  If you have a
> problem with that, contact the author of that specification.  Or, better
> yet, contact the web site (as far as I know, there are none) that has
> this security hole.
> 
> So, you think we're doing something bad.  Why don't you tell me what
> you think we should do?

A couple of points.  Firstly, I don't see a need for the referer header to 
"traverse" different domains.  For example, if I have a local page called 
"dorks.html", with a link pointing to, say, David Sternlights home page,
then he can deduce my opinion of him by looking at the referrer field.
This puts an unnecessary burden on my local bookmark web pages - I can no 
longer give the pages reasonable names (such as "dorks.html").

Secondly, a back button should not be implemented using referer headers.  If I 
have a back button on my page, I expect it to do what the Netscape back button 
does.  However, this is not what happens - back buttons built into web pages 
create a long chain of "forward" links. (I'm probably not explaining myself 
too well here).  What is really required is a special type of link that does 
exactly what the netscape back button does (and it would also be nice if I 
could put forward links in my pages too).

Perhaps the latter objection is do-able in Javascript - it's been some time 
since I tried.


Gary

In message <3351F2DF.7DC26A1A@netscape.com>you write:
...
>In the eyes of some, the referer header is a privacy violation.  It
>allows a site to see what site you visited before coming there.  In the
>case of Navigator, we ONLY send the referer header when you click on a
>link.  Not when you select a bookmark.  Not when you type a URL into the
>location field.  This allows web sites to see who links to them.  I
>think that's something that a web author is entitled to know.
>

Tom,

<ignoring personal privacy issues>

I am concerned that the referer field could be a major corporate security 
leak.  In particular, many companies are now using the web for internal 
project documentation.  The URLs often contain project code words or code 
names.  If a project wishes to to establish links to competitors for purposes 
of benchmarking, or to suppliers, the referer field would leak those code 
words and/or project organization.  In most security handbooks this is a 
breach of project security.  

Unfortunately, you (the commercial web community) are creating entitlements 
which the user community is likely to disagree with strongly.  My newspaper 
does not have an entitlement to know which pages I read, the advertisers in 
the newspaper do not have entitlements to the knowledge of which ads I scan.  
Assumption of such entitlements in the web environment will inevitably lead to 
privacy violations, security leaks and legal action.

-Bryan

> information.  This is a security hole in the web site, not in the
> browser.  The browser follows the HTTP specification.  If you have a
[. . .]
> 
> In the eyes of some, the referer header is a privacy violation.  It
> allows a site to see what site you visited before coming there.  In the
> case of Navigator, we ONLY send the referer header when you click on a
> link.  Not when you select a bookmark.  Not when you type a URL into the
> location field.  This allows web sites to see who links to them.  I
> think that's something that a web author is entitled to know.

	GET forms aren't the only thing wrong with referer, btw. An
associate of mine discovered some prioprietary Netscape information
from the Referer: headers on hits to his website from Netscape
employees, even.

	I commend Netscape for providing users with the ability to
turn off referers.

-- 
Sameer Parekh					Voice:   510-986-8770
President					FAX:     510-986-8777
C2Net
http://www.c2.net/				sameer@c2.net

Tom Weinstein wrote:
> Toto wrote:
> > Let's get real, here. Corporations add capabilities to their programs
> > that allow themselves and other 'major players' to have their way with
> > the user.
> >   When Joe Average, or a hacker/spammer takes advantage of the same
> > capability, then the vendors claim it is a 'bug', or that they can't
> > be blamed for the 'bad guys' use of this built-in function.
> 
> This is a security hole in the web site, not in the
> browser.  The browser follows the HTTP specification.  If you have a
> problem with that, contact the author of that specification.
> 
> In the eyes of some, the referer header is a privacy violation.  It
> allows a site to see what site you visited before coming there.

  And the Netscape default is to violate the user's privacy.

> This allows web sites to see who links to them.  I
> think that's something that a web author is entitled to know.

  Without notifying the user of your software that information
they may want to keep private is being given out? I don't think so.
  Why do you not instead require the web author to 'ask for 
permission' to know where the user last visited? Is it because
the user is just considered a pawn of business interests?
  
> So, you think we're doing something bad.  Why don't you tell me what
> you think we should do?

  My personal opinion is that you should inform your users of how,
when and why the use of your software does, or can, affect their
privacy. And you should give them an option of installing your
software with all privacy features set to 'on'.
  Give your users the option of not allowing their privacy to be
silently intruded on with no notification.

  The 'Cookie' situation is a good example of placing corporate
interests ahead of the interests of those who use a browser.
  The fact that the capacity to turn off cookie acceptance was
added after people found out and complained about their privacy
being violated is not something for companies to be proud of,
no matter how much their PR department may claim they are
championing privacy by adding these 'features'.

  I realize that the corporatization of the InterNet provides
certain benefits to users, but the fact of the matter is, the
cost of those benefits is being hidden from the users.
  I would just like to see a browser which informs the average
user in what way their information is being used and shared,
and gives them a way to protect themselves against intrusion
into their private lives and dissemination of their personal
information.

  Believe it or not, there may be users who stumble upon or
are suckered into going to a 'Bestiality and Child Perversion'
site who may not want to spread this information around.
  When I find out that a program's installation process has
stuck a hidden corncob up my ass, I'm not going to write them
a thank-you note if they later come up with a 'feature' to 
allow me to remove it.

  Please be advised that my email reply to you in no way indicates
a desire for my name to be sold to a 'Bestiality' mailing list,
despite whether or not this is part of some standard 'specification'
hidden in Netscape's fine print. (Cheap shot? Moi?)
  I use Netscape, and I like the different technologies being
developed that expand user's horizons. However, I would rather
be told what the cost is to have all of these 'free' capabilities,
and be given the option of bearing the burden of whatever increased
costs may arise by my not wanting to open my life and interests to
every operator of a roadside stand along the Information Highway.
-- 
Toto
"The Xenix Chainsaw Massacre"
http://bureau42.base.org/public/xenix/xenbody.html

Bill Stewart, ever the realist, despite the futility
of rational thought in confronting today's world, wrote:
> 
> At 01:54 AM 4/11/97 -0500, ARTURO GRAPA YSUNZA <agrapa@banamex.com> wrote:
> >See http://www.Microsoft.com/security/
> >under "Credit Card Security Concerns and Microsoft's Response"
> >for Microsoft's response on the SSL GET/POST weakness. ¿Any opinions?
> 
> I was highly unimpressed with Microsoft's Response:
>         "It's Not A Security Flaw"
>         "But Everybody Important Works Around It"
>         "And we're fixing it in the next release"
> without providing much detail about what's going on.
> It does indicate what to look into to avoid it when writing web pages,
> but it doesn't say how to avoid it when entering your credit card number
> into a web page, or what to look for as a non-programmer user.

  Bill seems to be one of the few people to realize that tips and
tricks for experienced programmers does nothing at all for the
common user, who has no way of discerning which of the programs
and sites that they access are indeed compensating for a system
which contains a plethora of basic faults.

  When facing a firing squad, there is little comfort in knowing
that only one or two of the rifles contain real bullets.
  Pardon me for suggesting that the average user will realize that
he need not volunteer to face the firing squad if he doesn't want
to. The 10,000 people who enter their credit card number at a
web page prompt won't be on the nightly news. The guy or gal whose
life was ruined when they did so, will be.
  Does anyone care to estimate what percentage of the 10,000 who
didn't get totally screwed will think twice before using their
credit card on the web again?
-- 
Toto
"The Xenix Chainsaw Massacre"
http://bureau42.base.org/public/xenix/xenbody.html

Bill Stewart wrote:
> 
> Thanks for the pointer to MS's security site; there's a lot of
> good information there.
> 
> I was highly unimpressed with Microsoft's Response:
>         "It's Not A Security Flaw"
>         "But Everybody Important Works Around It"
>         "And we're fixing it in the next release"
> without providing much detail about what's going on.
> It does indicate what to look into to avoid it when writing web pages,
> but it doesn't say how to avoid it when entering your credit card
> number into a web page, or what to look for as a non-programmer user.

I basically agree with Microsoft.  It works as specified, and everyone
should know that handling sensitive form posts via GET is a bad idea.

That said, there is certainly some merit to the argument that HTTP's
"Referer:" is a privacy violation.  Therefore, we've added a preference
to Communicator that allows you to turn it off.  Because of the late
date there will be no UI, but if you are concerned about it, you can go
into your prefs.js file (preferences.js on unix) and turn it off by
adding the line:

user_pref("network.sendRefererHeader", false);

This will be available starting in beta 4.

-- 
You should only break rules of style if you can    | Tom Weinstein
coherently explain what you gain by so doing.      | tomw@netscape.com

Tom Weinstein wrote:
> Bill Stewart wrote:
> > Thanks for the pointer to MS's security site; there's a lot of
> > good information there.
> >
> > I was highly unimpressed with Microsoft's Response:
> >         "It's Not A Security Flaw"
> >         "But Everybody Important Works Around It"
> >         "And we're fixing it in the next release"
> > without providing much detail about what's going on.
> > It does indicate what to look into to avoid it when writing web pages,
> > but it doesn't say how to avoid it when entering your credit card
> > number into a web page, or what to look for as a non-programmer user.
> 
> I basically agree with Microsoft.  It works as specified, and everyone
> should know that handling sensitive form posts via GET is a bad idea.
> 
> That said, there is certainly some merit to the argument that HTTP's
> "Referer:" is a privacy violation.  Therefore, we've added a preference
> to Communicator that allows you to turn it off.  Because of the late
> date there will be no UI, but if you are concerned about it, you can go
> into your prefs.js file (preferences.js on unix) and turn it off by
> adding the line:

  Nothing personal, but this is horseshit.
  I'm getting mighty tired of vendors claiming that the average user
is not getting hornswaggled by the new technology because they have
the option of becoming the world's foremost computer expert and 
disable all of the bullshit that is foisted upon them.
  I have yet to see an advertisement for a product that states that
the users, upon giving the vendor a pile of cash, will have a stick
shoved up their butt, but will also be able to remove it if they quit
their job and devote the rest of their life to figure out how to
disable intrusive computer mechanisms which intrude on their lives
and their privacy in a multitude of ways.

  Let's get real, here. Corporations add capabilities to their programs
that allow themselves and other 'major players' to have their way with
the user.
  When Joe Average, or a hacker/spammer takes advantage of the same
capability, then the vendors claim it is a 'bug', or that they can't
be blamed for the 'bad guys' use of this built-in function.

Major News Flash!!!
  If it is 'abuse' when I use it, then it is 'abuse' when the vendors
who programmed it that way use it, as well.

  I am awaiting the day when corporations and government finally 
resolve their differences and announce 'Cookie-Key Escrow'.
  I don't mind vendors implementing whatever schemes they choose,
I only resent their making the process obtuse and revealing what
they are doing only when getting 'caught' doing things in the
background that the average user might object to.
  Of course, I realize that I am being afforded the opportunity
to protect myself from unwanted intrusions by adding a "Fuck You"
line to my config.sys file, as long as I put it in front of the
second device file pointer which begins with the letter 'c', unless
it has more than two vowels in the line, in which case I have to
put my left foot behind my right ear and lick my balls twice.

  The bottom line? Why do I have to perform esoteric manipulations
to my system to defend myself from people I give money to in order
to be able to use that system?
  It sounds suspiciously like the protection rackets, to me.
-- 
Toto
"The Xenix Chainsaw Massacre"
http://bureau42.base.org/public/xenix/xenbody.html