Department C Incorporated (DCI) is an engineering research and development company with over 4 decades
of engineering, business, and policy experience in the networking and Internet arena.
It develops innovative networking products, solutions, and intellectual property.
Expertise includes
WiFi, embedded systems, IoT, NFC Tags, PKI, secure email, HSM design, protocols: LDAP,
TCP/IP, DNS, IPX, Q.921/931, H.323, X.509, DECNET, X.25, UUCP, MEP2, BiSync, SNA/SDLC. DNSSEC, NAT
Cross organizational end-to-end Outlook email security.
ES2ES plug-in provides DNSSEC validated s/mime smime certificate distribution to end users.
Supports rsa ecdsa ed25519.
S/MIME functionality available in Outlook
iy3xk ftc9ky
Outlook CERT_CHAIN_DISABLE_AIA
ES2ES
Ubiquitous end-to-end secure email
General Description
It seems reasonable in today's high tech environment to assume the secure
exchange of messages.
However, it is not. The vast majority of email still lies un-encrypted
on servers and only recently has there been interest in protecting it
during transfer between servers. Why?
Encryption technology is relatively mature and widely available.
It has even been a part of many popular email packages since 1999 based
on the S/MIME protocol.
Turning on this feature ensures messages, either in transit or lying on an
intermediate server waiting for transfer, cannot be read by anyone other
than its intended recipient.
The reason this feature is not on by default lies in key management.
Briefly, in order to send an encrypted message to a particular recipient,
you need to have their key.
These keys may be first exchanged between users or looked up on a server.
Universal secure message exchange would require this server to have keys for
every Internet user on the planet - a technical, security, and political
impossibility.
Hence, we have not seen secure email by default.
However, there is one "database" that every device on the Internet is already
connected to - the DNS.
It is distributed and scale-able, and with DNSSEC, secure.
Therefore, publishing keys in the DNS solves the key management problem.
The last remaining hurdle is how to get email packages to lookup a recipient's
key in the DNS and validate it with DNSSEC. This is where our ES2ES software
comes in by converting between email address book and DNS formats and
validating results with DNSSEC.
Getting started with ES2ES for Outlook
Supports DNSSEC ECDSA, ED25519, RSA end point validation!
Just download the program
here
and add as Outlook address book
sha256 hashes: 19e5ebd6af50b1996e2a69f5ff24a3f197ced58447d89a294c1bb15e4103911d=setup.exe, a6a6f280102de79fbc430cfdb0aaabe53b0c1677b12157db3a18898ff8839217=setup.msi (On Windows check with "certutil -hashfile setup.exe sha256")
OR
Skip to "Configuring Outlook to use ES2ES" and use our public test server* (ldap.ends2ends.com instead of your own server at 127.0.0.1:390) to try things out. MAC notes or Android notes.
OR
Create a test S/MIME+DNSSEC email account here to try it out.
Installing ES2ES
ES2ES is now a Windows Service. So after installation it automatically runs at startup. Just configure Outlook as follows.
Configuring Outlook to use ES2ES
FILE->Account Settings->Account Settings
Address Books->New
LDAP->Next
Server Name = 127.0.0.1:390 if using es2es or ldap.ends2ends.com if using public test server,
Next
OK
Finish
127.0.0.1:390 or ldap.ends2ends.com address book visible. Close and restart Outlook.
For the DNS/email hoster: Adding S/MIME certificates to your DNSSEC secured DNS
First generate a DNS record for the user's S/MIME certificate (and any intermiediate certs if not popular) by using a tool like this or sending a test email to checkme@ends2ends.com.
Add/upload the result into your DNS+DNSSEC server
Thats it
More about ES2ES
It basically is a miniature lightweight directory
access protocol (LDAP) server that runs locally on your machine. Applications like Microsoft Outlook
can directly query ES2ES for information that is otherwise unavailable and/or unsecured.
Currently ES2ES is
used to look-up S/MIME certificates in the public DNS (secured with DNSSEC) for email. This removes one
of the primary barriers to the widespread use of secured email, namely, certificate distribution.
With ES2ES installed I can send encrypted email without a previous exchange of certificates to anyone
who has published their certificate in the DNS using IETF RFC6698. Since ES2ES has its own Windows
native multi-threaded I/O DNSSEC validator, the look-ups are fast and secured end-to-end from email
source machine to destination machine.
ES2ES translates the LDAP ASN.1 style requests into equivalent DNS look-ups and validates the responses
using DNSSEC.
FAQ
What standards does ES2ES support? ES2ES is based on IETF RFC6698 and RFC8162 and will track updates in these standards. why?
What other platforms will ES2ES run on? Currently Windows 7-10 and 2012R2 server. We do have
plans to support other platforms if there is more interest.
What will be the post beta price? We plan on pricing the supported version in the $50USD range
for single units similar to other security middleware products on the market. Server and Site licenses would certainly afford a discount.
Will the public server support SSL? YES! Port LDAPS/636
Is the source code available? Source code is available under license.
We do also have a multi-threaded Linux version for the enterprise.
*Public Server notes:
Windows normally downloads any missing intermediate CA certificates by following the AIA fields up to a valid root. Hence, only a valid end point certificate is needed. Outlook, however, does NOT do this for LDAP certificates. So make sure you have a reasonably up to date certificate store. This is not a problem for native ES2ES service which follows Windows convention and downloads and validates intermediate certificates as needed in the background.
ES2ES
