• Welcome to Tux Reports: Where Penguins Fly. We hope you find the topics varied, interesting, and worthy of your time. Please become a member and join in the discussions.

HTTP and HTTPS sessions question

B

balzer

Flightless Bird
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.
 
B

Bob I

Flightless Bird
http://www.google.com/search?hl=en&...tack&aq=3&aqi=g10&aql=&oq=session+hi&gs_rfai=
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.
>
 
V

VanguardLH

Flightless Bird
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.
 
B

balzer

Flightless Bird
"VanguardLH" <V@nguard.LH> wrote in message
news:hq8d37$77o$1@news.albasani.net...
> 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.

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

One way can be restrict access to email service based on IP address. But
don't know email services which support this.
 
V

VanguardLH

Flightless Bird
balzer wrote:

> One way can be restrict access to email service based on IP address. But
> don't know email services which support this.


How would that work for dial-up users where their IP address changes every
time they negotiate a new connection with the DHCP server? IP addresses for
broadband users (DSL and cable) *do* expire. After, day, 3 days their
current IP address expires and they become "eligible" for a renegotiated IP
address from the DHCP server for whenever they unbind from the old IP
address, like when the user reboots their host (although some ISPs seem to
block further network traffic after some time for an expired IP address even
if the user doesn't unbind from the expired one). Very few user actually
have a static IP address assigned to them by their ISP.

There would be no way to guarantee that someone connecting with an IP
address some number of hours later was the same person that previously
connected using the same IP address. Users also travel with their laptops
or use computers at Internet cafes, libraries, resorts, and so on and
obviously those same users accessing their accounts would be using different
IP addresses.

Restricting access based on the IP address would work only for a few users
that have a static IP address and register it with the e-mail provider so
only that IP address can access a particular account. I suppose that is
possible but I haven't come across any e-mail providers providing this
restriction.

Also, restricting someone to a particular IP address to use a specific
e-mail account does NOTHING regarding the securing of the e-mail traffic
between the mail server and the host at that IP address. It also does not
address the securing of the content of e-mails past the mail server (i.e.,
for the *rest* of the route between sender and recipient).
 
Top