SSL Cipher Control

SYSTEM INFORMATION
RHEL 7.9
Webmin version 1.991

===============================================================
I have this config in /etc/webmin/miniserv.conf

port=10000
addtype_cgi=internal/cgi
realm=Webmin Server
logfile=/var/webmin/miniserv.log
errorlog=/var/webmin/miniserv.error
pidfile=/var/webmin/miniserv.pid
logtime=168
ssl=1
no_ssl2=1
no_ssl3=1
no_tls1=1
no_tls1_1=1
ssl_honorcipherorder=1
no_sslcompression=1
env_WEBMIN_CONFIG=/etc/webmin
env_WEBMIN_VAR=/var/webmin
atboot=1
logout=/etc/webmin/logout-flag
listen=10000
denyfile=.pl$
log=1
blockhost_failures=5
blockhost_time=60
syslog=1
ipv6=1
session=1
premodules=WebminCore
userfile=/etc/webmin/miniserv.users
keyfile=/etc/webmin/miniserv-202010-xxxxxxxx_key.pem
passwd_file=/etc/shadow
passwd_uindex=0
passwd_pindex=1
passwd_cindex=2
passwd_mindex=4
passwd_mode=0
passdelay=1
login_script=/etc/webmin/login.pl
logout_script=/etc/webmin/logout.pl
cipher_list_def=1
failed_script=/etc/webmin/failed.pl
nolog=.xhr.
extracas=
certfile=/etc/webmin/miniserv-202010-star_xxxxxx_com.pem
no_tls1_2=
ssl_redirect=0
logouttimes=
preroot=gray-theme
ssl_cipher_list=ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:!RC4:HIGH:-TLSv1:-TLSv1.1:+TLSv1.2:!RC4:!MD5:!ADH:!aNULL:!eNULL:!NULL:!DH:!ADH:!EDH
twofactor_provider=totp
root=/usr/libexec/webmin
mimetypes=/usr/libexec/webmin/mime.types
server=MiniServ/1.999

I’m using a Greenbone Security Assistant Vulnerabiltiy scanner.
It is enumerating these “Medium” ciphers being offered on port 10000 and 20000
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384

I don’t have any CBC based ciphers specified. I don’t know what I’m doing wrong with my configuration to not have it work for the ciphers I specified.

Have you checked what ciphers Apache is using (assuming you are using Apache)?

Dibs

I ran OpenSSL commands to enumerate my available ciphers. Apache isn’t listening on 10000 or 20000 and it should not be relevant to why “miniserv“ isn’t adhering to the cipher set I defined. I’m not understanding the point of the question.

Sorry mate - I assumed that it was Apache serving web pages and hence the question, but have realised webmin has it’s own perl web server.

No worries, I appreciate the community taking time to look at my query.

I’m wondering if it’s because I have “HIGH” entered in my ciphers list. I think that may be the issue. Probably if the server sees that directive it disregards my assigned cipher list.

What happens if you “turn off” all the entries after the 1st 4 ciphers?

The service won’t start. I tried putting in “Only the cipher list”. I had to ssh onto the box, edit the cipher list and return it to it’s previous condition to get the service to load.

FYI, I removed “HIGH” from the string. Again, the service wouldn’t reload. Had to ssh onto the instance and add “HIGH” back into the config. Frankly it doesn’t seem like miniserv doesn’t like “At all” specific definitions of ciphers. I’m still trying to figure out what the server wants in the config when you want it to honor the cipher list.

obviously “HIGH” is a defined list of ciphers in the miniserv module. Where is the list of “HIGH” ciphers located? I’ll just edit that?

When you did that (only putting in the cipher list) - the line ending was “clean”? i.e. no “:” at the end.

Assuming you did - bit annoying to say the least.

there is no “:” character at the end of the string.

Dibs if you want to see what ciphers your openssl installed version is capable of you can run a command something like:
openssl ciphers -v ‘ALL:COMPLEMENTOFALL’ | grep TLSv1.2 | grep ECDHE | column -t

1 Like

OpenSSL manages the ciphers and does have a .conf file - might be worth a check to see what it says.

There’s an issue number 412 in github for this very issue I’m asking about. @Moderators
 is this an outstanding bug issue?

Is this something to do with the way my OpenSSL 1.0.2k-fips interacts with the Net::SSLeay module? My version of that module is 1.55.

I learned that there’s a package necessary in RHEL called perl-IO-Socket-SSL necessary to correctly handle ECDHE ciphers (RHEL Buglist [Bug 1044401]). I wondered if that possibly could have contributed to why it was failing when I was trying to describe specific ECDHE ciphers in my cipher list.

This made me realize the the Perl modules dealing with SSL don’t very well implement some of the newer OPENSSL cipher suites. I reverted to what I was seeing in my scans:
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384

Then I reset my cipher string in Webmin config to read only:
AES256-GCM-SHA384:AES128-GCM-SHA256:!RC4:-TLSv1:-TLSv1.1:+TLSv1.2:!RC4:!MD5:!ADH:!aNULL:!eNULL:!NULL:!DH:!ADH:!EDH

After a re-scan:
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384

These are indeed the only cipher suites being enumerated by the scanner now.
I can be OK with the GCM based ciphers but didn’t want the cipher block chaining suites being offered. There are known vulnerabilities in those.
So the moral of this story is that perl-IO-Socket-SSL and perl-Net-SSLeay play a huge role in what SSL ciphers will be usable by the miniserv webserver even if your installed openssl supports better ciphers in apache, nginx, etc


This might be a takeway for developers. Implementation of the perl-IO-Socket-SSL and perl-Net-SSLeay modules where it concerns handling cipher suites might need updating? I only say this because I’m seeing where webmin has no idea what to do with any ciphers such as: ECDHE-RSA-AES256-SHA384

Cheers Chris - I’ll have a look tomorrow. Bit worn out messing about with Postfix.

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