SSL: Your Key to
E-commerce Security
|
The e-commerce
business is all about making money and then
finding ways to make more money. Of course, it's
hard to make (more) money, when consumers don't
feel safe executing a transaction on your Web
site. That's where SSL (Secure Socket Layer)
comes into play. Understanding how SSL affects
e-commerce business can also potentially help
you to unlock (more) money from your customers.
What is SSL?
Since its introduction in 1994, SSL has been the
de facto standard for e-commerce
transaction security, and it's likely to remain
so well into the future.
SSL is all about encryption. SSL encrypts data,
like credit cards numbers (as well other
personally identifiable information), which
prevents the "bad guys" from stealing your
information for malicious intent. You know that
you're on an SSL protected page when the address
begins with "https" and there is a padlock icon
at the bottom of the page (and in the case of
Mozilla Firefox in the address bar as well).
Your browser encrypts the data and sends it to the
receiving Web site using either 40-bit or
128-bit encryption. Your browser alone cannot
secure the whole transaction and that's why it's
incumbent upon e-commerce site builders to do
their part. EgisMail uses 128-bit encryption.
SSL
Certificates
At the other end of the equation, and of
greatest importance to e-commerce site builders,
is the SSL certificate. The SSL certificate sits
on a secure server and is used to encrypt the
data and to identify the Web site. The SSL
certificate helps to prove the site belongs to
who it says it belongs to and contains
information about the certificate holder, the
domain that the certificate was issued to, the
name of the Certificate Authority who issued the
certificate, the root and the country it was
issued in.
SSL certificates come in 40-bit and 128-bit
varieties, however, 40-bit encryption has been
hacked. As such, we strongly recommend that you look for
vendors using 128-bit certificates, like EgisMail, or if
you are looking for a certificate consider getting a 128-bit certificate.
Though there is a wide variety of ways in which you
could potentially acquire a 128-bit certificate,
there is one key element that is often
overlooked in order for full two-way 128-bit
encryption to occur. According to SSL
certificate vendor VeriSign, in order to have
128-bit encryption you need a certificate that
has SGC (server grade cryptography)
capabilities. |
Key Terms To Understanding SSL
SSL
Short for Secure Sockets Layer, a protocol
developed by Netscape for transmitting private
documents via the Internet. SSL works by using a
private key to encrypt data that's transferred
over the SSL connection.
digital certificate
An attachment to an electronic message used for
security purposes. The most common use of a
digital certificate is to verify that a user
sending a message is who he or she claims to be,
and to provide the receiver with the means to
encode a reply.
encryption
The translation of data into a secret code.
Encryption is the most effective way to achieve
data security.
DRM
Short for digital rights management, a system
for protecting the copyrights of data circulated
via the Internet or other digital media by
enabling secure distribution and/or disabling
illegal distribution of the data.
|
|
Domain Keys: Proving and Protecting
Email Sender Identity
Email spoofing - the forging of another person's or
company's email address to get users to trust and open a
message - is one of the biggest challenges facing both the
Internet community and anti-spam technologists today.
Without sender authentication, verification, and
traceability, email providers can never know for certain
if a message is legitimate or forged and will therefore
have to continually make educated guesses on behalf of
their users on what to deliver, what to block, and what to
quarantine, in the pursuit of the best possible user
experience.
Domain Keys is a technology proposal that can bring
black and white back to this decision process by giving
email providers a mechanism for verifying both the domain
of each email sender and the integrity of the messages
sent (i.e,. that they were not altered during transit).
And, once the domain can be verified, it can be compared
to the domain used by the sender in the From: field of the
message to detect forgeries. If it's a forgery, then it's
spam or fraud, and it can be dropped without impact to the
user. If it's not a forgery, then the domain is known, and
a persistent reputation profile can be established for
that sending domain that can be tied into anti-spam policy
systems, shared between service providers, and even
exposed to the user.
For well-known companies that commonly send
transactional email to consumers, such as banks,
utilities, and e-commerce services, the benefits of
verification are more profound, as it can help them
protect their users from "phishing attacks" - the
fraudulent solicitation for account information, such as
credit card numbers and passwords, by impersonating the
domain and email content of a company to which users have
entrusted the storage of these data. For these companies,
protecting their users from fraud emails translates
directly into user protection, user satisfaction, reduced
customer care costs, and brand protection.
For consumers, such as EgisMail! Mail users or a
grandparent accessing email through a small mid-western
ISP, industry support for sender authentication
technologies will mean that they can start trusting email
again, and it can resume its role as one of the most
powerful communication tools of our times.
How Domain Keys Works
How it Works - Sending Servers
There are two steps to signing an email with
Domain Keys:
- Set up: The domain owner (typically the team running
the email systems within a company or service provider)
generates a public/private key pair to use for signing
all outgoing messages (multiple key pairs are allowed).
The public key is published in DNS
(Domain Name Servers), and the private key
is made available to their Domain Key-enabled outbound
email servers. This is step "A" in the diagram to the
right.
- Signing: When each email is sent by an authorized
end-user within the domain, the Domain Key-enabled email
system automatically uses the stored private key to
generate a digital signature of the message. This
signature is then pre-pended as a header to the email,
and the email is sent on to the target recipient's mail
server. This is step "B" in the diagram to the right.
How it Works - Receiving Servers
There are three steps to verifying a signed email:
- Preparing: The Domain Keys-enabled receiving email
system extracts the signature and claimed From: domain
from the email headers and fetches the public key from
DNS for the claimed From: domain. This is step "C" in
the diagram to the right.
- Verifying: The public key from DNS is then used by
the receiving mail system to verify that the signature
was generated by the matching private key. This proves
that the email was truly sent by, and with the
permission of, the claimed sending From: domain and that
its headers and content weren't altered during transfer.
- Delivering: The receiving email system applies local
policies based on the results of the signature test. If
the domain is verified and other anti-spam tests don't
catch it, the email can be delivered to the user's
inbox. If the signature fails to verify, or there isn't
one, the email can be dropped, flagged, or quarantined.
This is step "D" in the diagram on the right.
In general, the MTA (Mail Transport Agent: EgisMail is a MTA) expects that
Domain Keys will be
verified by the receiving email servers. However, end-user
mail clients could also be modified to verify signatures
and take action on the results.
Several ways. First, it can allow receiving companies
to drop or quarantine unsigned email that comes from
domains that are known to always sign their emails with
Domain Keys, thus impacting spam and phishing attacks.
Second, the ability to verify sender domain will allow
email service providers to begin to build reputation
databases that can be shared with the community and also
applied to spam policy. For example, one ISP could share
their "spam vs. legit email ratio" for the domain
www.example.com with other ISPs that may not yet have
built up information about the credibility and
"spamminess" of email coming from www.example.com. Last,
by eliminating forged From: addresses, we can bring
server-level traceability back to email (not user-level -
we believe that should be a policy of the provider and the
choice of the user). Spammers don't want to be traced, so
they will be forced to only spam companies that aren't
using verification solutions.
Companies that are susceptible to phishing attacks can
sign all of their outgoing emails with Domain Keys and then
tell the world this policy so that email service providers
can watch and drop any messages that claim to come from
their domain that are unsigned. For example, if the
company www.example.com signs all of its outgoing email
with Domain Keys, EgisMail! can add a filter to its SpamGuard
system that drops any unsigned or improperly signed
messages claiming to come from the domain www.example.com,
thus protecting tens of millions of example.com's
customers or prospective customers from these phishing
attacks.
Hopefully! If they do, they'll make it easier for the
Internet community to isolate and drop/quarantine their
messages using the methods described above in "How will
this help stop spam?" Eliminating the uncertainty of "did
this email really come from the domain
example.com?" will facilitate a whole range of anti-spam
solutions.
Domain Keys examines the From: and Sender: headers'
domain to protect the user and deliver the best possible
user experience. Desktop mail clients like Microsoft
Outlook show these headers in their user interfaces. If
the user establishes their trust based on the these
domains, then so should any system built to verify whether
that trust is warranted.
Domain Keys signs the entire message to allow the
receiving server to also verify that the message wasn't
tampered with or altered in transit. By signing the
headers and the body, Domain Keys makes it impossible to
reuse parts of a message from a trusted source to fool
users into believing the email is from that source.
Domain Keys does not encrypt the actual message - it
only pre-pends a "digital signature" as a header.
Domain Keys currently uses an RSA (RSA is an
algorithm for
public-key encryption) public/private key
method. The key length is decided by the domain owner.
The domain owner, or an agent or service provider
acting on their behalf, should generate the key pairs that
are used for their Domain Keys-enabled mail system.
Domain Keys does not require a CA (Certificate Authority). Much like a trusted
Notary Public, Certificate Authorities are used in
public/private key systems to sign, or "endorse," public
keys so that the external users of public keys can know
that the public keys they receive are truly owned by the
people who sent them. Since Domain Keys leverages DNS as
the public key distribution system, and since only a
domain owner can publish to their DNS, external users of
Domain Keys know that the public key they pull is truly for
that domain. The CA is not needed to verify the owner of
the public key - the presence in that domain's DNS is the
verification. However, it is possible that Certificate
Authorities may become a valuable addition to the
Domain Keys solution to add an even greater level of
security and trust.
Domain Keys allows for multiple public keys to be
published in DNS at the same time. This allows companies
to use different key pairs for the various mail servers
they run and also to easily revoke, replace, or expire
keys at their convenience. Thus, the domain owner may
revoke a public key and shift to signing with a new pair
at any time.
S/MIME was developed for user-to-user message signing
and encryption and by design should be independent of the
sending and receiving servers. We believe that Domain Keys
should be a natural server-to-server complement to S/MIME
and not a replacement. Additionally, since S/MIME is used
by many security-conscious industries, we need to ensure
that the two technologies can work together without
breaking each other. Finally, S/MIME is not yet supported
by many of the email services, client software, and server
software used across the Internet, and in EgisMail's
opinion, that standardization effort would be much more
difficult than the standardization of Domain Keys.
Mailing lists that do not change the content or
re-arrange or append headers will be Domain Key compatible
with no changes required. Mailing lists that change the
message and headers should re-sign the message with their
own private key and claim authorship of the message.
Domain Keys will typically be implemented/enabled by the
team within a company, ISP, or email service provider that
deploys and runs the incoming and outgoing mail servers.
Some companies may have service providers that handle
their email. As MTA (Mail Transport Agent, EgisMail is a MTA) vendors add support for Domain Keys to
their products, the implementation of Domain Keys will
become simpler.
|