erroneous.netlify.app

While Encrypting a File with a Password from the Command Line using OpenSSL is very useful in its own right, the real power of the OpenSSL library is its ability to support the use of public key cryptograph for encrypting or validating data in an unattended manner (where the password is not required to encrypt) is done with public keys. The Commands to Run Generate a 2048 bit RSA Key. Mar 03, 2017  As I'd forgotten how to create a new OpenVPN user, it's not something I do every day, I thought I put here a reminder of the process used. To get a private key and a signed public key the easiest way is to use the Easy-RSA program that came with openvpn. Change to the directory.

• How Fast Does Openvpn Generate 2048 Rsa Keys
• How Fast Does Openvpn Generate 2048 Rsa Keyboard
• How Fast Does Openvpn Generate 2048 Rsa Key Generator
• How Fast Does Openvpn Generate 2048 Rsa Key Mac

They tell us we live in a hyper-mobile world. Not that I’d know: I rarely leave my home office. But of course I only get to enjoy the comforts of my home office because all the server resources I could possibly need are available remotely.

As Karsten notes, generating the RSA key is just your first step. You need to then generate a new self-signed certificate specifying that 2048-bit RSA key as the signing key. Then bind that new certificate to your interface. Only then will your scan show the SSL certificate as being signed using a 2048-bit key. Unable to generate keys for openvpn using easy-rsa. Ask Question. This will slow # down TLS negotiation performance # as well as the one-time DH parms # generation process. Export KEYSIZE=2048 # In how many days should the root CA key expire? Export CAEXPIRE=3650 # In how many days should certificates expire? Export KEYEXPIRE=3650 # These.

Apparently I’m not alone. Almost everyone whose work touches IT will access their professional tools from remote locations from time to time. And given that the public networks through which you access those remote locations are by their nature insecure, you’re going to want to carefully control those connections.

Website encryption is about making sure that the data consumed by your remote clients is reliably transferred and invisible to anyone who might be lurking on the connecting network. VPNs, by sharp contrast, focus on making sure that the data consumed by your remote clients is reliably transferred and invisible to anyone who might be lurking on the connecting network. Do you see the difference? Neither do I.

In fact, there are all kinds of technologies devoted to securing network communication, and the principle of _defence in depth_ teaches us that you should never rely on just one. So here’s where you’ll learn about _adding new_ layers of protection for your remote activities. Specifically, using encryption to build a virtual private network (VPN) tunnel to permit secure and invisible remote connections.

Building an OpenVPN tunnel

My Linux in Action book - from which this article is excerpted - talks a lot about encryption. SSH and SCP can protect data transferred through remote connections (chapter 3), file encryption can protect data at rest (chapter 8), and TLS/SSL certificates can protect data in transit between websites and client browsers (chapter 9). But sometimes your requirements demand protection across a broader range of connections, because sometimes you’ve got different kinds of work to do.

F’rinstance? Some members of your team need to work from the road using public WiFi hotspots. It’s definitely not smart to assume that random WiFi access points are secure, but your people do need a way to connect with company resources. VPNs to the rescue.

A properly designed VPN tunnel provides a direct connection between remote clients and a server in a way that hides data as it’s transferred across an insecure network. But so what? You’ve already seen lots of tools that can do that using encryption. The real value of a VPN is that once you’ve opened a tunnel, it’s possible to connect remote networks as though they’re all together locally. In a way, you’re circumventing that dodgy coffee shop hot spot.

Using such an extended network, admins can get their work done on their servers no matter where they might happen to be. But more importantly, as you can see in the figure, a company with resources spread through multiple branch offices can make them all both visible and accessible to all the teams who need them…wherever they are.

The mere existence of a tunnel alone doesn’t guarantee security. But one of a number of encryption standards can be incorporated into the design, making things a great deal better. Tunnels built with the open source OpenVPN package use the same TLS/SSL encryption you’ve already seen in use elsewhere. OpenVPN is not the only available choice for tunnelling, but it is among the best known, and it’s widely assumed to be a bit faster and likely more secure than the alternative Layer 2 Tunnel Protocol using IPsec encryption.

So that your team can safely connect with each other from out on the road or between multiple campuses, you’re going to build an OpenVPN server to permit sharing both applications and access to the server’s local network environment. To make it work, it should be sufficient to fire up two VMs or containers. One to play the role of a server/host and the other of the client.

How Fast Does Openvpn Generate 2048 Rsa Keys

Building a VPN involves quite a few steps, so taking a few moments to think about the big picture of how this is going to work will probably be worthwhile.

Configuring an OpenVPN server

Before getting started, here’s a helpful tip. If you’re going to follow along with this process on your own — and I strongly recommend that you do — you’ll probably find yourself working with multiple terminal windows open on your desktop, each logged into a different machine. Take it from me: at some point you’re going to enter a command into the wrong window and totally mess up your environment.

You can use the hostname command to change the machine name displayed on the command line to something that will visually remind you where you are. Once that’s done, you’ll need to exit the server and log back in again for the new setting to take effect.

Following that approach to assign appropriate names to each of the machines you’re working with should help you keep track of where you are.

Prepare your server for OpenVPN

Installing OpenVPN on your server requires two packages: openvpn and, to manage the encryption key-generation process, easy-rsa. CentOS users should, if necessary, first install the epel-release repository the way you did back in chapter 2. To give you an easy way to test access to a server application, you could also install the Apache webserver (apache2 for Ubuntu and httpd on CentOS).

While you’re setting up your server, you might as well do it right and activate a firewall that blocks all ports besides 22 (SSH) and 1194 (the default OpenVPN port). This example illustrates the way that will work on Ubuntu’s ufw, but I’m sure you still remember CentOS’ firewalld from chapter 9.

To permit internal routing between network interfaces on the server you’ll need to uncomment a single line (net.ipv4.ip_forward=1) in the /etc/sysctl.conf file. This will allow remote clients to be redirected as needed once they’re connected. To load the new setting, run sysctl -p.

The server environment is now all set up, but there’s still a way to go before you’re ready to flip the switch.

Generate encryption keys

When you installed OpenVPN, a /etc/openvpn/ directory was automatically created, but there isn’t a whole lot in it just yet. However, both the openvpn and easy-rsa packages come with sample template files that you can use as a base for you configuration. To jump start the certification process, copy the easy-rsa template directory from /usr/share/ to /etc/openvpn/ and then change to the new easy-rsa/ directory.

The first file you’ll work with is called simply vars, and contains environment variables that easy-rsa will use when it generates its keys. You will want to edit the file to substitute your own values for the sample defaults that are already there. Here’s what my file would look like:

Running the vars file will pass its values to the shell environment from where they’ll be incorporated into the contents of your new keys. When that’s done, the script will encourage you to run the clean-all script to delete any existing contents in the /etc/openvpn/easy-rsa/keys/ directory.

Naturally, your next step will be to run that clean-all script…followed by build-ca that will use the pkitool script to create your root certificate. You’ll be asked to confirm the identification settings provided by vars.

Next, the build-key-server script, since it uses the same pkitool script along with the new root certificate, will ask you the same confirmation questions to generate a key pair. The keys will be given names based on the argument you pass — which, unless you’re running multiple VPNs on this machine, would normally be server, as in this example.

OpenVPN will use parameters generated using the Diffie-Hellman algorithm (by running build-dh) to negotiate authentication for new connections. The file that will be created here does not need to remain secret, but must have been generated using the build-dh script against the RSA keys that are currently active. If you create new RSA keys at some time in the future, you’ll also need to update the Diffie-Hellman file.

Your server-side keys will now have been written to the /etc/openvpn/easy-rsa/keys/ directory, but OpenVPN doesn’t know that. By default OpenVPN will lookfor them in /etc/openvpn/, so copy them over.

Prepare client encryption keys

As you’ve already seen, TLS encryption uses matching key pairs, one installed on the server and the other on a remote client. That means you’re going to need client keys, and our old friend pkitool is just the thing to cook some up. This example, run while still in the /etc/openvpn/easy-rsa/ directory, passes client as an argument to generate files called client.crt and client.key.

The two client files, along with the original ca.crt file that’s still in the keys/ directory, will now have to be securely transferred to your client. Because of their ownership and permissions, this might be a bit complicated. The simplest approach is to manually copy the contents of the source file (and nothing but those contents) in a terminal running on your PC’s desktop (by highlighting the text, right-clicking over it, and selecting copy from the menu) and then pasting it into a new file of the same name you create in a second terminal logged into your client.

But anyone can cut and paste. Instead, think like an admin — especially since you won’t always have access to a GUI where cutting and pasting is possible. Instead, copy the files to your user’s home directory (so a remote scp operation can access them) and then use chown to change the ownership of the files from root to your regular, non-root user so that remote scp action can work. Make sure your files are all settled and comfy for now…you’ll move them over to the client a bit later.

With a full set of encryption keys ready for action, you’ll need to tell your server how you want to build your VPN. That’s done using the server.conf file.

Configure server.conf file

How are you supposed to know what the server.conf file should look like? Well, remember the easy-rsa directory template you copied over from /usr/share/? Well there are more goodies where that came from. The OpenVPN installation left a compressed template configuration file which you can copy over to /etc/openvpn/.

I’ll use the fact that the template is compressed to introduce you to a useful tool: zcat. You’re already know about printing a file’s text contents to the screen with cat, but what if the file is compressed using gzip? Of course, you could always decompress the file and cat will then be happy to print it, but that’s one or two steps too many. Instead, as you’ve probably already guessed, you can use zcat to load the decompressed text into memory all in one step. In our case, rather than print it to the screen, you’ll redirect the text to a new file called server.conf.

Leaving out the extensive and helpful documentation that comes with the file, here’s how it might look once you’re done editing. Note that a semicolon (;) tells OpenVPN _not_ to read and execute the line that follows.

Let’s work through some of those one at a time.

• By default, OpenVPN works over port 1194. You can change that — perhaps to further obscure your activities, or avoid conflicts with other active tunnels. But, because it will require the least coordination between clients, 1194 is normally your best choice.
• OpenVPN can use either the Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) for data transmissions. TCP might be a little bit slower, but it’s more reliable and more likely to get along with applications running at either end of the tunnel.
• You specify dev tun when you want to create a simpler and more efficient IP tunnel that transfers data content and nothing much else. If, on the other hand, you’ll need to connect multiple network interfaces (and the networks they represent) by creating an _ethernet bridge_, then you’ll have to select dev tap. If you haven’t a clue what all that means, go with tun.
• The next four lines pass OpenVPN the names of the three server authentication files and the dh2048 parameters file you created earlier.
• The server line sets the subnet range and netmask that will be used for assigning IP addresses to clients when they log in.
• The optional push “route 10.0.3.0 255.255.255.0” setting will allow remote clients to access private subnets “behind” the server. Making this work will also require network configuration on to server itself to ensure that the private subnet is aware of the OpenVPN subnet (10.8.0.0).
• port-share localhost 80 allows client traffic coming in on port 1194 to be rerouted to a local web server listening on port 80. This will be useful in our case since we’re going to use a web server to test our VPN. This will only work when proto is set to tcp.
• The user nobody and group nogroup lines should be enabled by removing the semicolons. Forcing remote clients to work as nobody and nogroup ensures that their sessions on the server will be unprivileged.
• log sets current log entries to overwrite old entries every time OpenVPN starts up, while log-append appends new entries to the existing log file. The openvpn.log itself will be written to the /etc/openvpn/ directory.

In addition, it is also very common to add client-to-client to the config file so multiple clients will be able to see each other in addition to the OpenVPN server.

Once you’re satisfied with your configuration, you’re ready to fire up the OpenVPN server.

Running ip addr to list your server’s network interfaces should now include a reference to a new interface called tun0. This will have been created by OpenVPN for the use of incoming clients.

It is _possible_ that you’ll need to reboot the server before everything will fully function. Next stop: the client computer.

Configuring an OpenVPN client

Traditionally, tunnels are built with at least two ends (otherwise we prefer calling them caves). Having OpenVPN properly configured on the server directs traffic into and out of the tunnel at that end. But you’ll need some kind of software running on the client side as well.

In this section I’m going to focus on manually configuring a Linux computer of one sort or another to act as an OpenVPN client. But that’s not the only way you might want to consume the service. OpenVPN itself maintains client apps that can be installed and used on Windows or Mac desktop/laptops, or Android and iOS smart phones and tablets. See the https://openvpn.net web site for details.

The OpenVPN package will need to be installed on the client machine, as it was on the server — although there’s no need for easy-rsa over here, because the keys you’ll use already exist. You will need to copy the client.conf template file over to the /etc/openvpn/ directory that the installation just created. This time, for some reason, the file won’t be compressed, so a regular cp will do the job just fine.

Most of the settings in your client.conf file will be fairly obvious: they’ll need to match the values used by the server. As you can see from the sample file below, one that’s unique is remote 192.168.1.23 1194 — which points the client to the server’s IP address. Again, make sure you use your server’s actual address. You should also force your client to verify the authenticity of the server certificate to prevent a possible man-in-the-middle attack. One way to do this is by adding the remote-cert-tls server line.

Now you can move to the /etc/openvpn/ directory and pull those certification keys from the server. You will obviously substitute your server’s actual IP address or domain name for the one in the example.

Nothing exciting is likely to happen until you start up OpenVPN on the client. Because you’ll need to pass a couple of arguments, you’ll pull the trigger from the command line. — tls-client tells OpenVPN that you’ll be acting as a client and connecting via TLS encryption while — config points to your config file.

Read the command output carefully to make sure you’re connected properly. If something does go wrong the first time, it’s probably either due to a setting mismatch between the server and client configuration files or perhaps a network connectivity/firewall issue. Here are some troubleshooting steps:

• Carefully read the output from the OpenVPN operation on the client — it will often contain valuable hints to exactly what it couldn’t do and why.
• Check for error-related messages in the openvpn.log and openvpn-status.log files in the /etc/openvpn/ directory on the server.
• Check OpenVPN-related and timely messages in the system logs on both the server and client (journalctl -ce will print out a screenfull of the most recent entries).
• Confirm that you’ve got an active network connection between the server and client (see chapter 14 for details).

This article is excerpted from my Manning “Linux in Action” book. There’s lots more fun where this came from, including a hybrid course called Linux in Motion that’s made up of more than two hours of video and around 40% of the text of Linux in Action. Who knows…you might also enjoy my Learn Amazon Web Services in a Month of Lunches.

OpenVPN devlopers tend to prioritize backward compatibility over security.This is not a general bad practise, but the current OpenVPN defaults aren't that well from a security perspective, in my opnion.In this post I hope to help you with 16 practical tips to a more secure OpenVPN setup.

By following the tips in this post it will help minimizing (or even full mitigation of) risks like:

• A man-in-the-middle attack.
• Future decryption of data in case of private key compromise (by enabling forward secrecy).
• Client key compromise allowing an attacker to impersonate a server.

The post may seem very large and overwhelming, I'm aware of that possibility.It just totally depends on what your're trying to protect with your OpenVPN installation.For protecting really secure networks (confidentiality) and the need for data integrity, please read up on all of it.For just bypassing a simple firewall without the specific needs of data encryption, this post is a probably a lot less relevant to you as by default OpenVPN is secure enough for you probably.

Unless mentioned otherwise, all configuration changes apply to both client and server configuration.Most changes require the client to update his configuration as well if changed later.If you're currently running on defaults with a large amount of clients you may want to apply all changes at once and plan the transition in a maintenance window.

In this post I'm assuming you're running OpenVPN version 2.3.x with TLS authentication (certificates, opposed to pre-shared keys).

In the client configuration, verify the server certificate subject string.For example:

Take this measure to prevent a client using his certificate to impersonate a server.

Certificates using the X509v3 format have key usage flags set.Clients should use certificates with the 'TLS Web Client Authentication' set and servers should be sending a certificate with 'TLS Web Server Authentication' set.Now configure OpenVPN to check for this:

For client configurations, connecting to servers:

For server configurations, accepting client connections:

Use an additional shared secret for authenticating the TLS handshake, minimizing (D)DoS attacks.The server and all clients should share the same secret to pass the initial TLS handshake.

Generate the shared secret:

For client configurations, connecting to servers:

For servers, accepting client connections:

Alternatively, embed the key and specify the key direction separately:

The latter approach appears to be incompatible with OpenVPN-NL.

With pregenerated Diffie-Hellman parameters the TLS session will be enabled (but not limited to) for use with TLS ciphersuites providing forward secrecy.This means that even if a malicious user got hold of the secret keys of any of the peers, he can still not decrypt the encrypted data intercepted.More on that in the last item.

DH parameters are considered public and it's hard to verify that those generated are actually strong.Unfortunately, OpenVPN does not ship with proven strong built-in DH parameters.

Only required on a server.

Generate a 2048 bits DH parameters file:

In the configuration:

For all certificates/keys, please use at least 2048 bits (RSA) as it's the minimum considered key size.By default older easy-rsa helper scripts generated all 1024 bits keys.Revoke and reissue all certificates/keys with a size lower than 2048 bits in size.If your situation allows you, use 4096 bits RSA key size.

A list of revoked certificates should be checked against to deny access with such a certificate.

When signing certificates the digital signature of the certificate to be signed is calculated.This hash (digest message) is the actual data being signed by the CA key for trusting it.It is of great importance you don't use MD5, SHA-1 or even weaker digests, because it is considered unsafe and someone could impersonate your server's or client's identity.

To check your certificate (or intermediate CA) signature, do

And it should output lines like these:

Any algorithm of the SHA-2 family (SHA-256, SHA-384, SHA-512) should be fine.

In typical use of certificates, clients' private keys are everywhere in your organisation and being used on many machines.The risk of them being compromised could be mitigated with revocation, but that won't help if keys have gone stolen unnoticed.

/office-2007-standard-product-key-generator.html. Instead of storing private keys on regular storage, it's a lot better to use a security device like a token or smartcard.Private keys on such devices will never leave it and cryptographic operations are performed on the card itself.This minimizes the risk in a private key compromise significantly.

OpenVPN can talk to PKCS#11 compatible devices. For setting up such a device, have a look at another post: Getting started with the SmartCard-HSM.

Select the right certificate by listing all on the token:

Where my-pkcs11-middleware.so is the path to the manufacturer provided middleware (shared library).For OpenSC cards using the OpenSC provided PKCS#11 middleware, use:

It will output something like this:

Then use it like this in your OpenVPN client configuration:

During the connection initiation the PKCS#11 middleware will ask for the security token passphrase.

While your connetion might be interrupted and OpenVPN is trying to reconnect, you may be using the default network routes again, bypassing the tunnel.For accessing private networks this might not be a big issue as the network addresses may not be reachable from outside the tunnel, but it may expose information you'd rather keep private like an HTTP request containing cookies.

To tell OpenVPN to keep the device open and to hold traffic until the connection restored, simply set the persist-tun option.

How Fast Does Openvpn Generate 2048 Rsa Keyboard

It's quite common in OpenVPN usage to have a server to send some client configuration parameters (push) over and the client to apply these (pull).If you just want to be sure your client configuration is exactly as you configured it, then consider to not include the pull option.This will require you to set up everything explicitly in the client configuration, and it may be severely impacting the ease of OpenVPN client deployments.

In normal configurations you'd want the OpenVPN daemon to configure the tun/tap device for you.(E.g.: configure the interface with the IP address assigned by the server.)However, you might want to consider doing it yourself, just to be sure in avoiding any command injection.Shellshock, anyone? ;-)

From the manpage:

In order to prevent any form of downgrade attack on the TLS protocol level, set on both clients and server the minimum version.If your clients and servers are modern (2.3.3+), they should support TLSv1.2 just fine, so you can configure it like this:

Note that this will break OpenVPN versions 2.3.2 and earlier, which only expect TLSv1.0 handshake signatures.

All items listed above are general TLS configuration options for your PKI, basically.For further security enhancements one could use OpenVPN-NL, a fork off OpenVPN using PolarSSL instead of OpenSSL as cryptography library and having more secure defaults.The items in below don't apply to OpenVPN-NL, because it already incorporates settings strong enough, or doesn't even offer other.I recommend at least considering using OpenVPN-NL instead of OpenVPN on your server and/or clients.In the meantime, apply the remaining items to a regular OpenVPN installation; they're chosen to be compatible with OpenVPN-NL.

Disclaimer: I'm employed by Fox-IT, the company developing OpenVPN-NL in collaboration with the OpenVPN community.

Not required for OpenVPN-NL.

How Fast Does Openvpn Generate 2048 Rsa Key Generator

OpenVPN's default encryption algorithm BF-CBC (Blowfish, block-cipher) with a 128-bit (variable) key size.While it's certainly not a terrible or 'broken' cipher like RC4 or single-DES, I prefer a more modern and widely used cipher like AES.Out of all other strong options, I've chosen AES-256-CBC for interoperability with OpenVPN-NL.

To see which other ciphers your version of OpenVPN supports, run

Not required for OpenVPN-NL.

Message authentication is what's referred to as HMAC.Using a HMAC is to ensure the encrypted data hasn't been altered in transit.OpenVPN's default setting is SHA-1.SHA-1 is considered weak since 2005 and Microsoft has announced their deprecation policy for it.The SHA-2 set of hashing algorithms are considered stronger and one should use those in favour of SHA-1 whenever possible.Out of the other strong options, I've chosen SHA-256 for interoperability with OpenVPN-NL.

To see which other HMACs are supported by your OpenVPN, run

Not required for OpenVPN-NL.

Limiting the list of TLS ciphers is recommended, because you want to enforce a secure cipher suite for the connection.Basically, you want to strip down the list OpenVPN offers a client to the ones you think are secure.This eliminates downgrade attacks or security issues in client configurations as well as the use of plain RSA key exchange.

From the OpenVPN manpage:

A list l of allowable TLS ciphers delimited by a colon (':').If you require a high level of security, you may want to set this parameter manually, to prevent a version rollback attack where a man-in-the-middle attacker tries to force two peers to negotiate to the lowest level of security they both support.

To see which TLS ciphers are supported by your OpenVPN, run

I'd recommend setting a small list of ciphers matching a commonly recommended set, for example:

The list above is basically a combination of the two strongest ciphers with regular OpenVPN (OpenSSL 1.0.1) and the two strongest offered by OpenVPN-NL, included for interoperability reasons.All of these are DHE or ECDHE enabled ciphersuites which means key exchange is done with Diffie-Hellman enabled, providing forward secrecy.ECDHE is preferred, because it is faster by the use of elliptic curve cryptography rather than the much slower plain Diffie-Hellman.

How Fast Does Openvpn Generate 2048 Rsa Key Mac

Cipher suite names have to be specified in IANA format, rather than OpenSSL format as you would normally find on the Internet.A mapping table from IANA to/from OpenSSL cipher suite names is available in the OpenVPN source code src/openvpn/ssl.c, for currently stable version 2.3.6 that is from line 116.Thanks to 'sosbar' in the comments to point that out to me.

Is something unclear?Do you have a remark on this post?Did I miss out on an important thing?Please let me know!Use the comments below or send me a tweet.

Do you like the post?Feel free to retweet or share in other ways!

Related Posts