balzer wrote:
> Some secure sites have HTTPS session stay secure from login till end of
> communication with site(log off).
> Some sites are HTTPS only when log in, after login, they become HTTP, and
> become HTTPS only when log off. (Yahoo mail for example, etc)
> What are the chances that session can be intercepted and sidejacked and
> traffic content recorded, especially as I know this danger really exists,
> and its carried purposefully and intentionally, by recording DSL traffic.
https://mail.yahoo.com
HTTPS is used to load the web page that present the input controls for you
to enter your login credentials. Once you send your login credentials (to
an SSL-secured server), you are switched to HTTP. It is ONLY the login
credentials that are getting protected. This is how it works for SSL
connects in e-mail clients, too. SSL is only used during user validation
(when USER and PASS commands are used to send the login credentials). The
rest of the e-mail session is sent as plain text, so anyone could sniff out
the contents of your e-mail traffic.
If you want to prevent anyone from sniffing your outbound e-mails, you will
need to encrypt them. That means you need the public key from the e-mail
certificate for the person to whom you are sending an encrypted e-mail.
That is, you need their public key to send them an encrypted e-mail (which
they then decrypt using their private key that only they have). They have
to send you a digitally signed e-mail to include their public key for you to
get it and then save in a contact record (which then you must use when you
later want to encrypt e-mail that you send to them using their public key).
http://www.hotmail.com
HTTP is used to paint the login page. It is unimportant that the web page
that present the inputs for login be secured. That page is rendered locally
in your web browser on your host and hasn't yet been sent anywhere with your
login data. When you send your login, Hotmail then connects to an
SSL-secured host. That means an SSL connection must be made BEFORE the
login credentials can be sent. It is only important that SSL/TSL be used
*when* you SEND your login credentials, not when you are typing them into
your web browser (which is something shown on your host and hasn't yet
transmitted anything). So users get concerned that the login page itself
isn't SSL-secured but it is irrelevant since that page was sent to YOU and
doesn't anything of your login credentials. It is to WHERE the data you
enter in the form for that web page gets sent that is important. If that
web page's form data gets sent to an SSL-secured server, the SSL connect
must be established before that data can be transmitted.
HTTP is used to present the login web page. HTTPS is used to actually
*send* your login credentials. Then you're back to HTTP when you connect to
their webmail client which means traffic is not encrypted and any packet
sniffer on your network can look at it. Like above, if you want to protect
your outbound e-mail traffic then you need to encrypt it using the public
key you got from the recipient to whom you send that encrypted e-mail.
If you want to receive protected e-mail traffic then you need to get the
sender to encrypt their e-mails using your public key. The data remains
encrypted until received into your e-mail client where it gets decrypted by
your private key that only you have. If you only use webmail clients to
access your e-mail account(s) then typically nothing of their traffic (other
than the login credentials) will be secure. Webmail clients cannot use your
e-mail cert to send encrypted emails (that only the recipient can decrypt)
or to receive encrypted traffic (that only you can decrypt). SSL/TSL takes
additional resources to handle and these mail servers have thousands if not
millions of users to handle concurrently. Free services are obviously
interested in handling the most customers with the least overhead.
http://www.gmail.com
HTTPS is used for the login page. And HTTPS is used for their webmail
client. This is the only webmail-based client (that I know of) for a *free*
e-mail provider that not only secures the login credentials but also the
traffic between you and their site (which means you reading your e-mails is
also secured from packet sniffers). Usually you have to get a paid e-mail
account to get HTTPS during the webmail session (but most paid e-mail
providers still don't provide SSL during the webmail session so you have to
check with them whether they do or not).
Typically SSL is used only for a webmail or local e-mail client during the
authentication to protect the login credentials. Thereafter the traffic is
plain text. Gmail is the exception regarding their webmail client. I have
not checked if, as typical, if Gmail drops the SSL connection after the
login authentication as is typical with other e-mail providers.
In general:
- For local e-mail clients, SSL is used only to secure the login
credentials, not the rest of the e-mail traffic.
* If you don't want your outbound e-mails sniffed out, encrypt them (using
the public key for the recipient to whom you send that encrypted
e-mail).
* If you don't want your inbound e-mails sniffed out, make sure senders
send you encrypted e-mails (using your public key).
- For webmail clients, SSL (HTTPS) is used only to secure the login
credentials which drops to HTTP when you view the webmail client's web
pages. Gmail is the exception that I know of (HTTPS is used for both
transmission of login credentials and display of webmail client pages).
Most users believe that enabling an SSL connection to their e-mail servers
protects all of their e-mail traffic. Wrong in the majority of cases. SSL
is only used to secure the login credentials, not the e-mail traffic.
That's why encrypted e-mails became important for those that actually want
to secure the *content* of their e-mails and not just their logins.
For local e-mails client connecting to mail servers, and even if the mail
server continued the SSL connection after the login authentication to also
secure all of the e-mail traffic, this traffic is only protected between
you and your mail server (and through whatever hosts are between you two).
Traffic sent between mail servers may pass through several hosts and it
won't be encrypted. You securing a third of the route (between you and your
sending mail server) still leaves insecure the route between mail servers
and also between the recipient and their receiving mail server (if they
don't use SSL connects which survive longer than just the login
authentication). Because the rest of the route between you and recipient is
not secure, there really isn't much point in securing the email traffic
between you and your mail server other than the login credentials.
This is like you running around nude inside your house with blacked out
windows but then dashing outside while still nude to get to your neighbor's
house that has glass walls. Your protected inside your house but exposed
while outside and even at the destination. You put on clothes while inside,
outside, or elsewhere to protect your privacy. You putting a postcard in
your locked mailbox to which only you and your mailman have a key is not
going to prevent anyone from reading that postcard after the mailman removes
it from your mailbox. After it's outside your mailbox, it is exposed during
the entire time it is getting delivered. You put an envelope around your
mails that you want to keep private.
If you want your outbound e-mails to be secure then encrypt them. If you
want your inbound e-mails to be secure then tell your senders to encrypt
them. Using SSL in a local e-mail client typically only secures your login
credentials, not your e-mail traffic. Webmail clients use SSL to only
secure the login credentials, not their web page traffic (with Gmail being
an exception). That only protects one portion of the entire route between
you and the other party involved in sending or receiving e-mails.
The Case for Email Security
http://luxsci.com/blog/the-case-for-email-security.html
There are lots of articles to find regarding SSL, login security, e-mail
traffic security, and encrypting e-mails just by Googling around.
Encryption hasn't caught on because it is a pain to setup and use. It is
not a pervasive or enforced setup. For example, to send an encrypted
e-mail:
- The other party has to first send you a digitally signed e-mail.
- When you receive their e-mail, it has their public key.
- You have to save them as a contact in your address book.
- That will save their public key in the contact record.
- Manually entering an e-mail address won't include their public key.
- Using cached manual entries won't include their public key.
- To encrypt an e-mail to them, you must use the contact record where their
public key got recorded.
- The encrypted e-mail is secure no matter if you do or don't use SSL to
secure your login credentials and/or e-mail traffic with the server. It
is protected even after your mail server in the rest of the route that
isn't secured.
- The recipient uses their private key to decrypt your e-mail.
You have to get their public key. You have to use their public key to
encrypt your e-mail that you send to them. They have to use their private
key to decrypt your e-mail. Usually the biggest efforts are expended in
getting an e-mail certificate and then importing it to your host so your
e-mail client can use it to digitally sign your outbound e-mails (to give
others your public key) or to decrypt incoming e-mails (that used your
public key). Thereafter, you either have to remember to manually add your
cert's public key to your outbound e-mails or configure your e-mail client
to always digitally sign your e-mails. Be warned that anything the modifies
your e-mail after you send it will violate your digital signature to the
recipient. An example of such corruption are anti-virus programs that
append a stupid and useless notice at the end of e-mails that purport the
sender scanned the e-mail before sending it (which is just text so it is
useless as any spammer/scammer could add that text, too). Another example
is using a freebie e-mail provider that appends their spam promotional
signature at the end of your e-mails. If you get a digitally signed e-mail,
you'll have to remember to save that sender in your contacts list so you can
later use their public key to encrypt your e-mails that you send to them for
which only they have their private key to decrypt it. Once setup, the
effort is minimal but it is the initial setup that scares off most users
from sending digitally signed or encrypted e-mails. Most users don't have
the gumption to even look at the user-configurable options for their e-mail
clients and come here begging for help on what they could already find.