[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SSL weakness affecting links from pa
Re: SSL & GET
I suspect that the pass-the-buck syndrome is in full force.
If the specs authors should realize that programmers are going to code
by them then shouldn't programmers realize that users are going to use
their products?
The user, the specification author, the browser manufacturer, the server
manufacturer, and the content provider all share the responsibility.
Just 'cause its in the specs doesn't mean (shouldn't mean) that everyone
else can just wash their hands of it. There are stupid users, stupid
specification authors, stupid browser manufacturers, etc. If the specs
are not secure the user shouldn't use it, the manufacturer shouldn't
code to it, etc. OR SHOULD THEY SHARE RESPONSIBILITY? I guess the real
solution will come in court when someone tries to sue a content provider
who tries to sue a server manufacturer who tries to sue a browser
manufacturer who tries to sue a specs author.
My concern is that the author of the comments, who works for Netscape by
the way, is passing the buck on to the content provider. Its great
policy for Netscape, bad policy Netscape's clients.
Re: HTTP REFERER
Useful? Yes. Entitled? NO.
Art Grapa
[email protected]
----------
From: Eric Murray
To: ARTURO GRAPA YSUNZA; [email protected]
Cc: [email protected]; [email protected]; [email protected]
Subject: Re: SSL weakness affecting links from pa
Date: Monday, April 14, 1997 12:45PM
Microsoft Mail v3.0 IPM.Microsoft Mail.Note
De: Eric Murray
Para: ARTURO GRAPA YSUNZA
[email protected]
Cc: [email protected]
[email protected]
[email protected]
Asunto: Re: SSL weakness affecting links from pa
Fecha: 1997-04-14 12:45
Prioridad: 3
Ident. del mensaje: 8C705E17CEB1D011AF91006097838CEB
-----------------------------------------------------------------------
----- --
ARTURO GRAPA YSUNZA writes:
>
>
> Tom Weinstein wrote:
>
> >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.
>
> Stupid programmers abound even in large corporations. Bugs, patches and
> security holes are now normal everyday things. I agree with Toto.
> Companies should take more responsability in the programs they produce.
No, specification authors should take more responsibility in the specs
that they produce. The HTTP spec's use of GET is insecure.
Specification
writers should realize that people will follow their specs, and should
be thinking of security and privacy issues as they are beig written.
> >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.
>
> NO WAY! The web author is NOT entitled to know where I came from. So if
> you go to Sears the saleperson is entitled to know you came from
> JCPenney's? If so, then I am just as much entitled to not tell him or at
> least entitled to know that there's a sign on my back that says where I
> came from. How many web users are aware of the HTTP REFERRER header? Not
> many, especially if they have not read the specs or looked at the logs
> from a web server. As an adminsitrator I AM NOT ENTITLED to that info.
Why not? It's a useful tool to find out who has linked to you.
On the other hand, it _is_ a privacy concern, and I don't want to send
it
to sites I visit. So I included an option blocking the Referrer tag in
Cookie Jar, the cookie-blocking program I wrote. I'd like to think
that
writing it helped push Netscape into supporting better options for
cookies
(see rfc2109) and into adding this option for not sending Referrer
but I'm sure there were many other louder calls for the same thing.
> Accept responsibility? Ok, that's wishful thinking. How about not
> blaming others? How about warning your users? You didn't do it in this
> case. If you do then you can say "I told you so!"
Users need to educate themselves. Even a fairly security and privacy
concious company like Netscape still has exectutives who feel as though
they have to answer to the bottom line and who will sacrifice consumer
privacy to get there if they feel that the advantages outweigh the
risks.
Netscape has consistently led industry in realizing and fixing and
admitting
security holes and privacy issues, largely due to the effort of Jeff and
the rest of their security group in educating upper management on those
issues and making them realize their importance. However I am not
willing
to bet my privacy on Netscape's good will, as it could turn at any time.
The way to real privacy is to educate oneself. Demanding companies to
"fix it" is lame and ineffectual. You have the technology- fix it
yourself! Distribute your code. Make the companies look bad.
Educate the sheeple. But asking companies to look out for your privacy
is a waste of time.
--
Eric Murray [email protected] Privacy though technology!
Network security and encryption consulting. PGP keyid:E03F65E5