IP addresses can be considered sensitive information. As such, Gmail may hide sender IP address information from outgoing mail headers in some circumstances.
Don't worry -- we aren't enabling spammers to abuse the system by not revealingIP addresses. Gmail uses many innovative spam filtering mechanisms to ensure that spammers have a difficult time sending bulk emails that arrive in users inboxes.
Google recently announced changes to their email service Gmail that would aid users in determining the real sender of an email message.
Also
Google actually has added a series of improvements to Gmail. Emails from a sender who is not already in a Gmail user's contacts are now shown prominently in the header. This change makes it easier to identify the sender directly without having to look at all email headers.
But the changes do not stop here. It sometimes happens that someone sends an email for another user or from another website, for instance by using a web form. This is now also reflected in the email header directly. Gmail users now see the name of the sender as well as the sender's email address and a via link.
Probably the biggest change from an anti-phishing point of view is a new warning that appears if Gmail believes that the email could have been sent by someone else. Gmail shows a "This message may not have been sent by" warning underneath the sender with links to learn more and to report a phishing email.
All three additions are visible directly when an email has been opened on the Gmail website. The new information improve security for all Gmail users, provided that those users pay attention to the notifications and additional information.
Especially the first two additions can be overlooked easily due to their gray font color on white background. The phishing warning on the other hand uses a yellow background so that it can be easily spotted by everyone. (via)
Also
Well, if you want to take a significant step in keeping prying eyes away from your electronic correspondence, one good encryption technology that predates Google altogether is worth looking at. It's called public key encryption, and I'm sharing some instructions on how to get it working if you want try it.
Unfortunately, better security typically goes hand in hand with increased inconvenience. But some human rights activists who used Gmail right now likely wish they'd put up with a little hardship to help keep hackers at bay. I'm not going so far as to recommend you use e-mail encryption, but I think this is a good time to take a close look at it.
Specifically, I'll show here how to use a collection of free or open-source software packages:GPG, or GNU Privacy Guard, Mozilla Messaging's Thunderbird e-mail software, and itsEnigmail plug-in. CNET Download.com also hosts Thunderbird for Windows and Mac andEnigmail for all platforms.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
SSL encryption
It's strangely difficult to find out exactly how SSL works with email, at least insofar as answering my specific question - when I connect to gmail using SSL, I understand that my connected is secure and thus data is all encrypted between MY COMPUTER and the GMAIL SERVER. However, is that all SSL does? For example, when I open an email on my computer, the data between Mountain View (or whatever) and my house is encrypted? Would that mean then if I email my friend who also uses gmail with SSL/secure gmail enabled, then if I send an email also with an attachment to his gmail account that email as well as the attachment are encrypted at my computer, sent to GMail server, and then provided my friend uses SSL then he can security acquire the email too? So there is no need for those firefox encryption addons? Are those just for more robust encryption algorithms? gmail sends emails to google servers with HTTP. gmail also retrieves emails from google servers with HTTP. when you connect to the google servers using https (as opposed to http) then the connection between your gmail client and the gmail servers is secure and data is encrypted going back and forth between the two. when using a client (thunderbird for example) SMTP is used to send emails, and IMAP/POP are used for retrieving emails. At the add-on/options level, you can tell these clients to use TLC for both the SMTP and IMAP/POP steps. The google servers probably don't use TLS with SMTP when bouncing emails back and forth amongst their servers. Conclusion - if using gmail, always use HTTPS but know there is no encryption between google's servers, but in the 'outside world' the connection between google clients (as long as using https) is secure. if using thunderbird (or something else) turn on TLS.
So in summary, here is what I think I have learned (and provides a summary for others reading). PLEASE CORRECT ME IF I AM WRONG:
SSL types
The mutual version is more secure, but requires the user to install a personal certificate in their browser in order to authenticate themselves.SSL comes in two options, simple and mutual.
Whatever strategy is used (simple or mutual), the level of protection strongly depends on the correctness of the implementation of theweb browser and the server software and the actual cryptographic algorithms supported.
SSL does not prevent the entire site from being indexed using a web crawler, and in some cases the URI of the encrypted resource can be inferred by knowing only the intercepted request/response size.[11] This allows an attacker to have access to the plaintext (the publicly-available static content), and the encrypted text (the encrypted version of the static content), permitting a cryptographic attack.
Because SSL operates below HTTP and has no knowledge of higher-level protocols, SSL servers can only strictly present one certificate for a particular IP/port combination.[12] This means that, in most cases, it is not feasible to use name-based virtual hostingwith HTTPS. A solution called Server Name Indication (SNI) exists, which sends the hostname to the server before encrypting the connection, although many older browsers do not support this extension. Support for SNI is available since Firefox 2, Opera 8, Safari 2.1, Google Chrome 6, and Internet Explorer 7 on Windows Vista.[13][14][15]
If parental controls are enabled on Mac OS X, HTTPS sites must be explicitly allowed using the Always Allow list.[16]
From an architectural point of view:
- An SSL/TLS connection is managed by the first front machine that initiates the SSL connection. If, for any reasons (routing, traffic optimization, etc.), this front machine is not the application server and it has to decipher data, solutions have to be found to propagate user authentication informations or certificate to the application server, which needs to know who is going to be connected.
- For SSL with mutual authentication, the SSL/TLS session is managed by the first server that initiates the connection. In situations where encryption has to be propagated along chained servers, session timeOut management becomes extremely tricky to implement.
- With mutual SSL/TLS, security is maximal, but on the client-side, there is no way to properly end the SSL connection and disconnect the user except by waiting for the SSL server session to expire or closing all related client applications.
- For performance reasons, static content that is not specific to the user or transaction, and thus not private, is usually delivered through a non-crypted front server or separate server instance with no SSL. As a consequence, this content is usually not protected. Many browsers warn the user when a page has mixed encrypted and non-encrypted resources.
A sophisticated type of man-in-the-middle attack was presented at the Blackhat Conference 2009. This type of attack defeats the security provided by HTTPS by changing the https: link into an http: link, taking advantage of the fact that few Internet users actually type "https" into their browser interface: they get to a secure site by clicking on a link, and thus are fooled into thinking that they are using HTTPS when in fact they are using HTTP. The attacker then communicates in clear with the client.[17]
In May, 2010, a research paper[18] by researchers from Microsoft Research and Indiana University discovered that detailed sensitive user data can be inferred from side channels such as packet sizes. More specifically, the researchers found that an eavesdropper can infer the illnesses/medications/surgeries of the user, her family income and investment secrets, despite HTTPS protection in several high-profile, top-of-the-line web applications in healthcare, taxation, investment and web search. This finding points out a unique challenge on information leaks that HTTPS faces on the era of web 2.0.
Sent from my iPad
No comments:
Post a Comment