Encrypting the Net: Use “Let’s Encrypt” SSL to Set Up Secure Website Traffic

February 1, 2016 | Views: 5124

Begin Learning Cyber Security for FREE Now!

FREE REGISTRATIONAlready a Member Login Here

Hello,

This guide comes out of inspiration from the Course offered here not too long ago: SSL Traffic: The Cyber Criminal’s Best Friend Instructed By Darrin Coulson.

I’ll start with a bit of basic background knowledge you should have on what SSL (Secure Sockets Layer) Encryption is, and how it benefits us.

SSL (Secure Sockets Layer) is a basic security protocol for establishing an encrypted link between a web server and a client.

With a normal web connection, an attacker is able to intercept all data being sent between a browser and a web server. They can see and use that information how they like, because it’s transmitted in Plain Text.

Please keep in mind that all browsers have the capability to interact with secured web servers using the SSL protocol. However, the browser and the server need what’s called an “SSL Certificate” to be able to establish a secure connection.

 

How the process goes:

  1. Browser connects to a web server (website) secured with SSL (HTTPS). Browser requests that the server identify itself.
  2. Server sends a copy of its SSL Certificate, including the server’s public key.
  3. Browser checks the certificate root against a list of trusted CAs and ensures the certificate is unexpired, unrevoked, and that its common name is valid for the website it’s connecting to. If the browser trusts the certificate, it creates, encrypts and sends back a symmetric session key using the server’s public key.
  4. Server decrypts the symmetric session key using its private key and sends back an acknowledgement, encrypted with the session key to start the encrypted session.
  5. Server and Browser now encrypt all transmitted data with the session key.

 

Why SSL is so important?

SSL is essential in protecting data from being spied upon by someone else on the internet because they will not be able to understand the encrypted data.

When you type a search into Google.com or Bing.com, it’s not very hard for someone to eavesdrop on the phrase you’re searching for. Similarly, when you log into Facebook, it’s not difficult to intercept and decipher your password while it’s in transit between your computer and Facebook’s servers. And, when you send payment information to PayPal, a hacker cannot listen in and swipe your credit card number.

SSL helps do away with Man-In-The-Middle Attacks. But, as everyone who has tried to get and maintain a certificate for a web server before will tell you, it’s no easy task.

 

Here’s where Let’s Encrypt comes in

Let’s Encrypt automates every single step: from no validation emails, to no complicated configuration editing, to no expired certificates breaking your website. And, of course, because Let’s Encrypt provides certificates for free, there’s no need to arrange payment.

1 $ git clone https://github.com/letsencrypt/letsencrypt
2 $ cd letsencrypt
3 $ ./letsencrypt-auto --help

 

The Let’s Encrypt script will install all of its own dependencies and updates client code automatically.

If you’re running Apache on Debian-based Operating System, you can try the Apache plugin included, which automates both obtaining and installing the SSL certs:

./letsencrypt-auto –apache

To get a cert using the “webroot” plugin, which works with the webroot (www) directory of any webserver software:

./letsencrypt-auto certonly –webroot -w /var/www/example -d example.com

The this will obtain a single cert for example.com, www.example.com, thing.is, and m.thing.is; it will place files below /var/www/example to prove control of the domain.

 

After doing this , you’ll have to configure your web server to use the SLL Certificate you have just created. To do this:

edit the: httpd-ssl.conf Apache configuration file.

To locate this file on your server, open a Terminal , and type:

Locate httpd-ssl.connf

Inside this file, you’ll need to create a virtual host configured to use port 443 (which needs to be port forwarded, if on your own connection)

<VirtualHost *:443>

 

#   General setup for the virtual host

DocumentRoot “/opt/lampp/htdocs/example.com”

ServerName www.example.com:443

ServerAdmin examle@example.com

ErrorLog “/opt/lampp/logs/error_log”

TransferLog “/opt/lampp/logs/access_log”

#   SSL Engine Switch:

#   Enable/Disable SSL for this virtual host

#   SSLEngine on

#   Server Certificate:

#   Point SSLCertificateFile at a PEM encoded certificate.  If

#   the certificate is encrypted, then you will be prompted for a

#   pass phrase.  Note that a kill -HUP will prompt again.  Keep

#   in mind that if you have both an RSA and a DSA certificate, you

#   can configure both in parallel (to also allow the use of DSA

#   ciphers, etc.)

#   Some ECC cipher suites (http://www.ietf.org/rfc/rfc4492.txt)

#   require an ECC certificate, which can also be configured in

#   parallel.

SSLCertificateFile “/etc/letsencrypt/live/example.com/cert.pem”

SSLCertificateKeyFile “/etc/letsencrypt/live/example.com/privkey.pem”

SSLCertificateChainFile “/etc/letsencrypt/live/example.com/chain.pem”

#SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire

<FilesMatch “.(cgi|shtml|phtml|php)$”>

SSLOptions +StdEnvVars

</FilesMatch>

</VirtualHost>

—————————————–

Make sure you edit the following accordingly. This tells Apache where to look for the Certification that Let’s encrypt created:

SSLCertificateFile “/etc/letsencrypt/live/example.com/cert.pem”

SSLCertificateKeyFile “/etc/letsencrypt/live/example.com/privkey.pem”

SSLCertificateChainFile “/etc/letsencrypt/live/example.com/chain.pem”

 

Once you have your web server configured, close the file and restart the server.

Now, you should be able to visit your domain on it’s encrypted port 443:

https://example.com

An SSL Certificate from Let’s Encrypt looks something like this:


With this, I hope I was able to help some of you out there trying to Encrypt your Servers connection. Thank you.

I also want to take the opportunity to thank @trevorh for helping me out with submitting this and getting my issues with OP3N resolved.

“Conformity is the jailer of freedom and the enemy of growth.”

https://github.com/krintoxi/

Share with Friends
FacebookTwitterLinkedInEmail
Use Cybytes and
Tip the Author!
Join
Share with Friends
FacebookTwitterLinkedInEmail
Ready to share your knowledge and expertise?
19 Comments
  1. great articl , thank’s

  2. OK, I like the idea [no money down SSL certs] and I disagree with an earlier poster who pointed to a blog entry on LinkdIN to a gentleman who staunchly opposes CAs of EVERY current variety whose conclusions apparently stem directly from the the Snowden leaks of June 2013 and going forward. However, like others my primary concern is one of authenticity. On first perusal it appears ever so easy for anyone to obtain certs in any domain. I suspect there are multiple classes of attacks, including MitM and domain hijacking, that are just too easy with such a resource at hand.
    For these reasons and many more it’s a great discussion topic and I’m glad you posted here.
    This is fast becoming my GoTo site for IT issues, learning, and ideas for self-study.

    • Please note :”This is not a self signed certificate, this is signed by Let’s Encrypt Certificate Authority. ?
      “The objective of Let’s Encrypt and the ACME protocol is to make it possible to set up an HTTPS server and have it automatically obtain a browser-trusted certificate, without any human intervention. This is accomplished by running a certificate management agent on the web server.”
      “Let’s Encrypt identifies the server administrator by public key. The first time the agent software interacts with Let’s Encrypt, it generates a new key pair and proves to the Let’s Encrypt CA that the server controls one or more domains. This is similar to the traditional CA process of creating an account and adding domains to that account.”
      https://letsencrypt.org/howitworks/technology/

      Con..

    • Please also note: “Let’s Encrypt issues certificates to subscribers from its intermediate CAs, allowing them to keep their root CA safely offline. IdenTrust has cross-signed the intermediates. This allows their end certificates to be accepted by all major browsers while we propagate their own root.
      “When configuring a web server, the server operator configures not only the end-entity certificate, but also a list of intermediates to help browsers verify that the end-entity certificate has a trust chain leading to a trusted root certificate. Almost all server operators will choose to serve a chain including the intermediate certificate with Subject “Let’s Encrypt Authority X1” and Issuer “DST Root CA X3.” The official Let’s Encrypt software will make this configuration seamlessly.”
      The following picture explains the relationships between certificates visually:
      https://letsencrypt.org/certs/isrg-keys.png

  3. Great information! Thanks for posting this and for also putting it on Github (which I just followed you). You have an incredible amount of information! Thank you for sharing!

Page 2 of 2«12
Comment on This

You must be logged in to post a comment.

Our Revolution

We believe Cyber Security training should be free, for everyone, FOREVER. Everyone, everywhere, deserves the OPPORTUNITY to learn, begin and grow a career in this fascinating field. Therefore, Cybrary is a free community where people, companies and training come together to give everyone the ability to collaborate in an open source way that is revolutionizing the cyber security educational experience.

Cybrary On The Go

Get the Cybrary app for Android for online and offline viewing of our lessons.

Get it on Google Play
 

Support Cybrary

Donate Here to Get This Month's Donor Badge

 
Skip to toolbar

We recommend always using caution when following any link

Are you sure you want to continue?

Continue
Cancel