Email Transit Security Needs Better Adoption

05 Aug

Email transit security is not a new concept, but it deserves more attention in terms of adoption and practice.

Email has become the key component for information access – every online service identifies you through your email id. All online transactions (not just financial transactions) have one or more transactional email sent to you. Examples of transactional emails are – file share notifications, password reset mails, shipment notifications and account information change notifications. Despite not having direct financial information, all these mails have potential to compromise the security of an individual or company’s information.

We all take ample care while accessing our emails over a secure connection using tools like Thunderbird, Outlook or web based secure access. These secure connections ensure that  email is accessed securely from a mail server to a client device like desktop or phone. However, what is the assurance that the mail actually traveled from the sender to the mail server in a secure way?

Securing email during transit is not a new concept. There are enough protocols and processes in place for ensuring email security during transit. However, email security during transit isn’t adopted by all major service providers and organizational senders. This poses risk to the information carried over by emails to individuals and organizations.

Google’s safer email campaign and email transparency report focus on documenting metrics and best practices related to email transit security.  A couple of pictures on this page describe how TLS helps ensure security of email in transit.

Adoption of TLS for email transit security is not a unilateral fix by one or more ISPs. When email is hopping between two ISPs, it requires both the ISPs to agree upon the use of TLS for transmitting the email. So none of the ISPs or individual organizations can claim that they send/receive all their emails over a secure channel. At the time of writing this article, only 74% of mails from Google are accepted by recipients over secure connection. That number is much better, when compared to the 54% mails received by google from other ISPs over secure connection.

There are several techniques employed by eavesdroppers to make meaningful information out of even non-confidential content.  Ensuring email transit security helps an organization in the long run. Even if security of mail content is not of prime concern for an organization today, it is highly recommended that the email is sent securely during transit. That way, the organization is not giving away information easily to the eavesdroppers.

To trust, or not to trust

20 Jul

Do you trust? That is a vague question. It is very difficult to reply to this question with a definitive answer.

Do you trust [something]? That is a better question. Most likely, one will be comfortable to give a specific answer.

Do you trust [someone]? Here comes the complexity. The process of determining to trust someone has sevaral factors to weigh in. Trusting a person almost always requires an action or objective to qualify with, so that the affirmation of trust can be deduced. Trusting a non-human also requires additional qualification, but with a non-human, the purpose is mostly inherent and intended.

When I read this article on New York Times about the evolution of trust, it raised a few questions about trust and how we model in in computing and compute driven social environments. The computability of (or quantifying) trust and deduction of trust is, in general, an ever evolving and complex problem.

For non-humans we encounter in digital world, the establishment of trust is thru hashes, digital certificates, digital signatures, etc. and are continuously solved by entities like EMC’s RSA. For example, we may readily trust a PGP signed email or a shopping site that is protected by an SSL Certificate.

Trusting humans we meet online is nothing new. Social networking sites took the concept of acquaintance to a new dimension. Social Networking is slowly morphing the concept of acquaintance to a basis of trust establishment. For example, how many Facebook applications did you install (and trust) recently? How many people (those you have never met in the real world) did you befriend online and as a result, trusted them with your contacts, some amount of personal details, pictures, etc.? More often than not, social networking thrives on establishing trust beyond the immediate circle of acquaintance. Alluring to trust a friend of a friend  is the concept on which social networking thrives.

Shopping sites like EBay and Amazon have rating systems both at the product level and at seller level. Most of these ratings are based on previous transactions and respective human responses. The ratings quantify the transaction and response information to form a basis for trust. Customers make shopping transactions that are heavily influenced by these seller and product ratings.

Those two needs of trusting humans, for digital information and shopping transactions, have certain level of intrusion into the personal space. But the intrusive nature of services like Airbnb into one’s personal space is more physical and prominent.  The concept of giving someone (you possibly don’t know) access to physical resources has a considerable mental barrier. Service providers in this space will continuously try to lower that barrier or find ways to pass that barrier with quantified computation of trust. New dimensions of trust establishment are likely to emerge for solving this need. This space is likely to go beyond simple rating systems by the service providers.

 

 

More from openssl last week

09 Jun

The heartbleed bug might have created pressure schedules for many a system administrators and security practitioners around the globe, but it definitely has done a few good things. One great outcome of heartbleed is closer scrutiny of the openssl code and use cases, that is going to help the secure online activities in the long run.

Last week, openssl released a few more patches and people jumped on it right away. The issues involved are not as serious as heartbleed (actually, no where closer), but the attention these patches have got is good.

Broadly, there are two major vulnerabilities that are of interest to me from that set.

  • SSL/TLS MITM vulnerability (CVE-2014-0224): The vulnerability requires both client and server to be running vulnerable versions of openssl, so this was relatively easy to fix. This vulnerability exploits the weakness in ChangeCipherSpec phase of the SSL handshake and that is a small, but practical window of opportunity for the attacker. Also, connectionless services are impacted to a greater level (say, streaming) than connection oriented services. That made this particular vulnerability a very important one to fix, but not a super critical one from a timeline standpoint.
  • SSL_MODE_RELEASE_BUFFERS NULL pointer dereference (CVE-2014-0198): This vulnerability would cause potential injection into a stream and would lead to DOS attacks. Luckily, none of the key sites I work with are using this flag explicitly set on apache and nginx based servers.

Rest of the vulnerabilities are not so critical for the kind of environments I work on. However, patching in either of the above cases would lead to well patched servers for all these vulnerabilities.

So it was a good week/weekend that involved verify and patch than rush and fix.

 

DKIM, RFCs and Interpretations

28 May

I have been working on DKIM for the last couple of years and the journey has been very interesting.  Started with simple DKIM signing of mails and eventually spent considerable time on Signer Actions and Verifier Actions best practices. The later part is, to put it in a nutshell, an amazing experience.

If you live on the leading edge of any Internet technology that needs multi-vendor support and is cross-platform, you would know how critical the RFCs (http://www.ietf.org/rfc.html) turn out to be. As RFCs (and the respective consumers) evolve, the room for interpretation of the constructs in RFCs increase and you would see a lot of discussion around these interpretations.

Here is an example related to DKIM. For quite some time, all the DKIM signing entities are used to publishing public key records in the following format

“k=<proto>\; p=<pubkey>”

The above format is minimal and functional format for quite some time. For example, this is what gmail uses for this particular selector 20120113:

$ dig +short @ns1.google.com 20120113._domainkey.gmail.com txt
“k=rsa\; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1Kd87/UeJjenpabgbFwh+eBCsSTrqmwIYYvywlbhbqoo2DymndFkbjOVIPIldNs/m40KF+yzMn1skyoxcTUGCQs8g3FgD2Ap3ZB5DekAo5wMmk4wimDO+U8QzI3SD0” “7y2+07wlNWwIt8svnxgdxGkVbbhzY8i+RQ9DpSVpPbF7ykQxtKXkv/ahW3KjViiAH+ghvvIhkx4xYSIc9oSwVmAl5OctMEeWUwg8Istjqz8BZeTWbf41fbNhte7Y+YqZOwq1Sd0DbvYAD9NOZK9vlfuac0598HY+vtSBczUiKERHv1yRbcaQtZFh5wtiRrN04BLUTD21MycBX5jYchHjPY/wIDAQAB”

However, in the recent weeks, there is a growing set of ISPs that are mandating the other fields of a DKIM record. For example, RFC 5863 discusses DKIM verifier considerations in Appendix 1.2. The considerations around the DNS record talk about

If a DKIM verifier finds a selector record that has an empty “g” field (“g=;”) and it does not have a “v” field (“v=DKIM1;”) at its beginning, it is faced with deciding if this record was:

1. from a DK signer that transitioned to supporting DKIM but forgot to remove the “g” field (so that it could be used by both DK and DKIM verifiers); or

2. from a DKIM signer that truly meant to use the empty “g” field but forgot to put in the “v” field. It is advised that you treat such records using the first interpretation, and treat such records as if the signer did not have a “g” field in the record.

Looks like the notion of an empty “v” field is generating lot of noise from a few ISPs in the recent weeks. Even though the field is deemed optional, the interpretations by these ISPs have some ripple effects on how the other fields (like the granularity field) are seen in such situations.

Having read this RFC (and RFC 6376) a few times back and forth, it is time to test the DNS records by adding a  “v” field. I should be able to see the impact on those ISPs that changed their interpretations recently.

 

Knock, Knock. Who is this?

18 May

Viruses knock your doors quite often. You should ask the right questions before letting anyone in.

For the last 2+ weeks, a specific version of Skype virus is on unleash and impacted many people I know. The virus looks more like a nuisance initially, but has the potential to impact the infected systems to a greater level.

The virus spreads itself with a message that looks like this “When was the last time you saw this photo [link]”. This message is broadcasted to all the contacts of a compromised account. Once the recipient clicks on the link, multiple things are observed to happen to the system. Firstly, the message is now broadcasted to the contacts of the newly compromised account. Secondly, the system leaves a trace of itself on the system. More often, the firewalls on the impacted Windows systems are turned off and the skype settings for the user are set in such a way that arbitrary programs can be executed by skype sessions.

The virus also appears to have two variants, in terms of the messages it sends – the URL can be a generic URL or a personalized URL that includes the skype id of the recipient. The second variant, IMO, has a better hit rate – who would normally ignore a link that is so personalized?

There are multiple fixes recommended for impacted systems/accounts.

  • Make sure that skype settings are changed to not execute arbitrary / external code. Instructions at this post would help.
  • Make sure you run Malwarebytes or any other good anti-virus
  • Make sure that your Windows firewall is turned on.

Not clicking on such links is a prerequisite though.

 

 

VPN tunnels over smartphones

08 Mar

As the enterprises are shifting more towards smart phone based access of company wide resources, the emphasis on establishing a secure connection between the nomadic device (read cell phone or tablet) and the enterprise is increasing. A tablet is mostly seen as an evolution of laptop and hence is expected to run applications like VPN clients anyway. However, a smart phone is more of an extension of the voice communications device and its ability to establish a secure “tunnel” back home requires a bit of digesting.

US National Security Agency (NSA)’s mobility program recently published the Mobility Compatibility Package Guide. This guide talks about various architectural components of the Secure Smartphone VOIP over cellular network. The key requirements presented in this guide is an interesting read.

One of the key challenges would be to manage the applications on the mobile device from provisioning and security viewpoints. That would most likely require a VPN tunnel between the device and the enterprise using the carrier network.

BTW, if you have an android smartphone and if you need to setup a VPN tunnel using that, see this article by Jack Allen.

This time, Google gives back to Internet Users

22 Jul

Bruce Schneier wrote an article on Google’s finding of unusual search patterns and eventual discovery of malware. Quoting directly from Google’s article,

Recently, we found some unusual search traffic while performing routine maintenance on one of our data centers. After collaborating with security engineers at several companies that were sending this modified traffic, we determined that the computers exhibiting this behavior were infected with a particular strain of malicious software, or “malware.”

As Schneier aptly puts it,

There’s a lot that Google sees as a result of it’s unique and prominent position in the Internet. Some of it is going to be stuff they never considered. And while they use a lot of it to make money, it’s good of them to give this one back to the Internet users.

The comments on Scheier’s article are worth reading for all security enthusiasts.

 

Discussion on National/International cybersecurity frameworks

16 Mar

It is always enlightening to read contradicting viewpoints that are substantiated with good reasoning and ample evidences. Read this article by Prescott Winter and this related article by Alec Muffett. Can we ever have cybersecurity frameworks and/or laws that cut across national boundaries? Or, should we, in the first place?

I am personally more inclined towards Alec’s thoughts. Right from 1969, Internet has been more de facto than de jure. It is good to have standards, policies and processes drive the expectations (say, something like ISO 27001) and various roles in a delivery process adhere to the rights and responsibilities on data handling. That adherence can always  be strengthened with liability regulations of the land. That works much better than International cybersecurity laws.

Facebook and security

27 Jan

This particular blog entry by Alex Rice of facebook unveils a couple of new features on horizon. I tried out https:// based access and found that applications like chat won’t work during https:// based access. I am also curious about the 2nd feature: identification of a friend for authentication: What if you use proxies that are situated across the globe within a short time?

Also read this related interesting article. It gives an interesting perspective of security on social networking sites.