[email protected] (Timothy Sipples) writes:
> Yahoo! Mail -- the Web version -- *still* does not use HTTPS for most
> communications AFAIK. For example, if you're using a free wi-fi hotspot at
> a coffee shop, and you access Yahoo! Mail via their Web interface,
> practically everything except your login credentials flows in the clear. A
> fairly unsophisticated attacker can intercept that traffic and spoof your
> browser -- and access all your e-mail -- for up to 7 calendar days (the
> default timeout).
>
> Security professionals have been warning Yahoo! and criticizing them for a
> decade. Google Mail and Microsoft Hotmail, among others, don't have the
> problem. (Google has always encrypted its Web UI for e-mail.) Yes,
> implementing HTTPS costs money. So do security breaches!
>
> In short, don't access Yahoo! Mail over any network that you don't trust --
> or, better yet, don't access Yahoo! Mail over the Web at all. Access via
> IMAP -- iPhone or iPad, as examples -- using the built-in mail client is
> encrypted. Access via the free Zimbra Desktop software is also encrypted,
> to pick another example. Or don't use Yahoo! Mail at all.

re:
http://www.garlic.com/~lynn/2012j.html#47 Yahoo Password Breach: 7 Lessons 
Learned - Security - Attacks/breaches - Informationweek

we were doing ha/cmp cluster scaleup ... some old email
http://www.garlic.com/~lynn/lhwemail.html#medusa

possibly within hrs of the last email in above (end jan1992), the
scaleup was transferred, we were told we couldn't work on anything with
more than four processors, and a couple weeks later there was IBM
supercomputer announcement (for scientific and numeric intensive *ONLY*)
... and we decide to leave.

this old post reference meeting early Jan1992 in Ellison's conference
room
http://www.garlic.com/~lynn/95.html#13

two of the other people mentioned in that meeting later leave and showup
at a small client/server startup (responsible for something called the
"commerce server"). we get brought in as consultants because they want
to do payment transactions on their server; the startup had also
invented this technology called "SSL" that they want to use.

As part of the effort we need to map the technology into business
process of payment transactions, establish the requirements for SSL use
to meet security assumptions, as well as do audits and walk thoughs of
these new business processes selling merchant domain name SSL digital
certificates (result is now frequently referred to as "electronic
commerce") ... some past posts
http://www.garlic.com/~lynn/subpubkey.html#sslcert

SSL was to meet two objectives 1) is the webserver that you think you
are talking to actually the webserver you are talking to and 2) hide
(aka encrypt) payment/sensitive information being transmitted through
the internet.

For "SSL" to meet #1, the requirements are that the end-user know the
relationship between the webserver they think they are talking to and
the URL they type into the browser; then "SSL" establishes the
relationship between the URL entered and the webserver actually talked
to. Almost immediately the requirements for #1 are violated, commerce
servers find that "SSL" cuts their throughput by 85-95% ... and they
drop back to using "SSL" for just entering payment information (aka #2,
but there no longer is assurance that the webserver that you think you
are talking to is the webserver you are talking to).

You enter a non-SSL URL ... so there is little assurance that you
actually are talking to that webserver. Then sometime later, you click
on payment/checkout button .. which provides the SSL URL (not you) ...
so it violates the first part of #1 requirement, no longer any
understanding between the webserver you think you are talking to and the
URL you enter (the SSL assurance devolves to the webserver you are
talking to is whatever webserver that the webserver claims to be).

-- 
virtualization experience starting Jan1968, online at home since Mar1970

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to