J. Debert writes about an insecure Web page at http://www.kponline.org.
It happens that my best friend works for Kaiser Permanente's IT department,
so I forwarded the message to her. As a result of discussions and
exploration, I think that the alleged risk does not in fact exist.
The claim was that medical-record numbers were being exposed during the
signon process. However, in viewing the source of the referenced Web page,
it appears that the "sign on" button makes an https (SSL) connection. Thus,
although the "padlock" icon in the browser is unlocked, anything sent from
that page is in fact sent using SSL.
I have recommended that Kaiser change their main page so that it forwards
the browser to an SSL equivalent, solely so that the padlock icon will
appear locked.
I think that the true RISK is not in Kaiser's Web page, but rather in the
browser. The "padlock" icon reflects not whether the page SENDS information
securely, but rather the fact that the page was FETCHED securely. This
disconnect between what is shown and what is expected has been raised
recently by Jeff Mogul in the converse direction: a page that had the
padlock proceeded to send information insecurely.
The first problem (apparently insecure page is actually secure) can be
patched around with the forwarding kludge I mentioned above. The second can
be handled by the user to some extent (certain browser settings can warn you
when you transition from a secure page to an insecure one). However, the
true problem is in browser design. The "padlock" icon should be associated
with a LINK, not a page. Regardless of how it was fetched, if a page
contains both secure and insecure links, the lock should be shown as
unlocked and should lock only when you mouse over a secure link. Only if
all outgoing links from a page are secure should the padlock be permanently
displayed in its locked form.
Geoff Kuenning geoff@cs.hmc.edu http://www.cs.hmc.edu/~geoff/ [Geoff Kuenning via risks-digest Volume 21, Issue 87]
0:00
#
G!
