Authentic theme using SSLv3 even when disabled

5 posts / 0 new
Last post
#1 Fri, 08/25/2017 - 12:02
scotwnw

Authentic theme using SSLv3 even when disabled

Reproduced this many times. Authentic theme causing SSLv3 for server to server connections. Webmin/cloudmin host is Ubuntu 12.04 and remote system is Ubuntu 16.04. I have just switched to Authentic theme since I read somewhere its speed has been improved. And it is faster than before. But ran into issue. All but TLS1.2 is disabled on all my webmin configurations via, webmin, webmin configuration, SSL encryption. On the Cloudmin/webmin server, when I click 'open webmin' for a remote system, If the remote system has authentic theme on as the default, Firefox complains its using SSLv3 and blocks any further progress. "Firefox cannot guarantee the safety of your data on blahblah.com because it uses SSLv3, a broken security protocol". Same goes for when I click webmin servers index and try to connect from there. If I change the remote system back to Grey Framed theme. And try connecting again. Connects fine and https info from green lock Icon says its using TLS1.2. If I change the remote system back to authentic, Firefox complains its using SSLv3 again.
Authentic is enabled on the main host. But becomes an issued when also enabled on the remote server.

So Authentic is forcing SSLv3 somehow for server to server comms? Or an error is preventing TLS for connections between two authentic systems? Theme should not be affecting the connection type.

Webmin 1.851 and cloudmin 9.3 on the server. Authentic 18.49-8

Remote pc is webmin 1.850. No update showing up for 1.851 on it yet. Authentic 18.49-8 when enabled.

Fri, 08/25/2017 - 14:19
scotwnw

Ran another test. Doesn’t matter which system uses authentic vs grey frames theme. But if both do, Firefox says SSLv3 is being used.

Fri, 08/25/2017 - 19:37
Joe
Joe's picture

Hmmm, I'm not sure how that'd happen, actually. The Webmin web server is what determines the available protocols and the theme has no control over that. I'll try to reproduce and see if I can figure out what's happening.

--

Check out the forum guidelines!

Fri, 08/25/2017 - 19:48
Joe
Joe's picture

I can't reproduce this. My Cloudmin instance always uses TLS 1.2 even when connecting to other Webmin instances.

One thing that can adversely affect server-to-server connections is a firewall blocking ports 10001-10010. Webmin uses those for its "fast RPC" communication method. I can't think of how that would trigger this behavior, but I do know that Webmin falls back to the old RPC method which uses just port 10000 if it can't connect to the higher ports. So, maybe that old code doesn't correctly handle protocol selection right, and maybe the older themes don't open enough connections to trigger the problem...maybe? I dunno, this is really weird behavior.

But, see what happens if you open up those ports on both the Cloudmin master and the systems it's connecting to. Let me know if that fixes it; if so, I'll put Jamie on the case. If not, I'll have to come up with a new theory. This probably isn't a good theory, but it's all I've got at the moment.

--

Check out the forum guidelines!

Sat, 08/26/2017 - 00:12
scotwnw

Previous tests I did where when I was logging in from an Ubuntu desktop 14.04 Firefox. Just did same test in windows Firefox and no error. Goes to TLS1.2 no problem.

(via remote desktop) Logged back into the same desktop that gave the error earlier today, did same test in same firefox. No error. Hmm. I recorded it earlier so I'm not crazy. haha. Possible cache issue on my end maybe since I have Firefox clear cache/history on exit and no error now. Tested on Ubuntu 16, 14, and windows Firefox. None showing issue now. I'll advise if it crops up again.

Thanks for checking.

Topic locked