I tested my SSL and got B. Is there any way of improving that?

openssl should update via apt.
try:
sudo apt install openssl
[see what that says]

I get:

sudo apt install openssl
Reading package lists... Done
Building dependency tree
Reading state information... Done
openssl is already the newest version (1.1.1-1ubuntu2.1~18.04.6).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 Like

Yes, but not in Ubuntu 16.04 LTS… At least, I heard someone saying that in Ubuntu 18.04, it comes updated already. I didn’t check if it’s true. But I’ll try to do as you said.

That's not going to work... Sorry I missed this line in the original post...

OpenSSL maxes out at 1.0.2g on Ubuntu 16.04

The options are:

  1. Upgrade the Ubuntu distribution to 18.04 (has 1.1.1) or 20.04 (1.1.1-f)
  2. Migrate from the Ubuntu package to the Nginx repo -- i'm not sure what nginx version is supported here though (nginx: Linux packages)
  3. Build openssl and nginx from source. The custom openssl lives alongside the nginx. Uninstall the Ubuntu nginx, and then build the custom nginx against the new openssl installation.

It's worth migrating to 20.04 - or, if its an option - doing a fresh 20.04 install.

2 Likes

This is what I’ve got:

Reading package lists… Done
Building dependency tree
Reading state information… Done
openssl is already the newest version (1.0.2g-1ubuntu4.16).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

1 Like

Exactly!!! But there’s a big downside: is it possible to upgrade from 16.04 to 18.04, without needing to reinstall the Nginx server, phpmyadmin, mysql, php 7.0…? I wouldn’t like to rebuild my vps and do it all again…

1 Like

The standard upgrade path with Ubuntu is that you would invoke sudo apt update && sudo apt dist-upgrade to move from 16.04 - 18.04, then immediately do it again to migrate from 18.04 to 20.04; there isn't a migration path directly from 16.04 to 18.04.

However...

I was recently in the same situation as you. The changes between 16.04 and 18.04 are much more substantial than those between 18.04 and 20.04. 90% of the work I did in migrating to 20.04 was handled in the 18.04 changes. So you could do an automatic upgrade and stop at 18.04, but it's not going to be much more work to go all the way to 20.04 and you can just get all that over with now.

I ended up doing a fresh 20.04 install; my "changes" were largely updating what my automated build/deploy scripts did (small changes to paths, some services had config options change). While I preferred how some things in 16.04 worked, 20.04 is a lot more standardized across the board and easier to configure and use.

1 Like

That sequence of apt commands won’t work without editing some sources.list files, but that’s a very Debian thing :smiley:

Canonical being Canonical there’s a command to do version advancement: do-release-upgrade

2 Likes

Yes. There are handful of other things in the upgrade guides, which should always be followed! The abbreviated version though, is that to upgrade from 16 to 20, one first upgrades from 16 to 18, then immediately upgrades again from 18 to 20.

1 Like

Look, I’ve got to reach 100% in cipher strength. Now how can I reach 100% on Key exchange?

1 Like

Try a larger RSA key size (2048 is the minimum).
Or
Switch to ECC
Or
Provide BOTH types :slight_smile:

2 Likes

I’m not sure I like how you did it. No TLSv1.3 and a single TLSv1.2 cipher? https://www.ssllabs.com/ssltest/analyze.html?d=olimppi.us&hideResults=on

However, yes, the first thing to do is to up keysize to 4096 bits RSA or to ECC p-256 or p-384 or a configuration with both an rsa 4096 and an ecc certificate.

1 Like

Don’t you mean DH without the E? Ephemeral and/or elliptic curve DH is fine I thought?

1 Like

Removing all 128 Cipher did the job.

RSA 2048 -> 4096 - that’s the key exchange.

But that doesn’t work with EC certificates. Don’t know why, my own domain has an EC 384, but no 100 % Key Exchange.

1 Like

yeah, I’m not saying it doesn’t work, I’m saying it looks rather… restrictive of an overkill.

Mine does. Let me check.

https://www.ssllabs.com/ssltest/analyze.html?d=check-your-website.server-daten.de&s=2a01%3A238%3A301b%3A0%3A0%3A0%3A0%3A1226&hideResults=on&latest

Here: ssllabs doesn’t like the x25519 or secp256r1 curves for 100% key exchange. (but they only show in handshakes and cipher lists, not under supported named groups)

1 Like

Ah, thanks, good to know.

But I don’t want to kill

Android 5.0.0 EC 384 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
Android 6.0 EC 384 (SHA256) TLS 1.2 > http/1.1 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS

these two clients. Don’t think Windows 10 has another cipher suite that will work.

That’s the general problem with such a test: Restricting too much doesn’t increase the security of other clients (they use ECDH secp384r1), but blocks some clients. And A+ is good enough, 4 * 100 % isn’t required.

@roguitar88 : 4 * 100 % isn’t so relevant. You have other, more critical things. Grade C - non-www + www without a preferred version, cookie warnings, missing defer. That’s more relevant.

PS: And no ipv6, missing external SRI, that’s bad.

1 Like

On my server they connect like this:

Android 5.0.0 RSA 4096 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp521r1 FS
Android 6.0 EC 256 (SHA256) TLS 1.2 > http/1.1 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 ECDH secp384r1 FS

But you go for ECC-only, that doesn’t work for you. And windows 10:

IE 11 / Win 10 R EC 256 (SHA256) TLS 1.2 > h2 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDH secp384r1 FS
Edge 15 / Win 10 R EC 256 (SHA256) TLS 1.2 > h2 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDH secp384r1 FS
Edge 16 / Win 10 R EC 256 (SHA256) TLS 1.2 > h2 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDH secp384r1 FS
Edge 18 / Win 10 R EC 256 (SHA256) TLS 1.2 > h2 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDH secp384r1 FS
2 Likes

I’m also almost coming to the conclusion that having 100% in all 4 parameters is not that relevant… So… Would there be any problem about leaving it so?

1 Like

It's relevant that you have minimal 80 % per check and no critical warnings.

I have 2 * 100 and 2 * 90 %, that's ok.

Somewhere Ssllabs says: 2048 bit are ok -> that's not 100 %.

More important is HSTS and these other things. There you have errors you should fix.

PS: Sample: If you use an external Javascript without SRI and that external server is hacked, it's like an amazing XSS hack.

PPS:

Is SSL Enough?

No. A non-trivial web site cannot be secure if it does not implement SSL, but SSL is not enough. SSL deals with only one aspect of security, and that is the security of the communication channel between a web site and its users. SSL does not and cannot address a number of possible security issues that may exist on a web site. View SSL as a foundation on which to build, but the foundation alone is not enough.

The SSL configuration checked via Ssllabs is only one small part. If your website has other fundamental errors or if Sql-injections or Xss hack are possible, your Grade A+ doesn't help.

1 Like

Pretty understandable

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.