TLS negotiation failed with status IllegalMessage
WHM 72.0 on CentOS 7.5
After a server migration, Outlook.com (live.com) > "Connected Accounts" cannot connect to any of my cPanel email accounts anymore. I feel like I'm missing a config value somewhere to have it working like before, does anybody know?
In live.com connected account setup, when I choose SSL as the encryption, it displays this error: TLS negotiation failed with status "IllegalMessage".
When I choose TLS or NONE, it displays this error: We were unable to reach your email provider. Please check your server settings, or try again later.
Under Service Configuration > Mailserver Configuration, I only have these values, is this normal or is it missing a bunch of other protocols?
Allow Plaintext Authentication (from remote clients) = yes
SSL Cipher List = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
SSL Protocols = TLSv1.2
I also tried another SSL hostname that points to the same server, same thing. I also tried DIRECTLY with the IP instead of mail.xxxxxxxxx.com and it still does the same thing so at least I know there's a configuration problem on my WHM server, and that it's not a DNS resolution cache at Microsoft's.
Anybody knows what the missing config values are?
-
Anybody at all? Got 2 angry customers who haven't been able to get their email using Outlook connected accounts and that's the only way they want to get their email. It has to be fixed ASAP. 0 -
OK thanks, I read the other forum post you linked. So, just to be clear, in my case it has nothing to do with Outlook 2016 on Windows. Sending/Receiving in the Windows desktop app works fine. I'm talking about OUTLOOK.LIVE.COM connected accounts (The one on Microsoft's web page, not the app on the desktop) right, so I monitor: tail -f /var/log/maillog Then after pressing the NEXT button in OUTLOOK.LIVE.COM connected accounts setup form, nothing happens for a while but then after 20 seconds, this appears in my server's maillog: Jul 30 14:00:23 secure dovecot: pop3-login: Disconnected (no auth attempts in 20 secs): user=<>, rip=40.97.114.253, lip=[MY_SERVERS_IP], TLS handshaking: Disconnected, session= Then immediately when this error pops up in the maillog, on Microsoft setup page, it displays: We were unable to reach your email provider. Please check your server settings, or try again later. I traced back 40.97.114.253 as Microsoft Azure server in Des Moines, Iowa, so I'm almost sure this is the one. OUTLOOK.LIVE.COM connected accounts uses TLSv1.2 right? Nothing nowadays uses 1.1 right? (I mean no web service such as OUTLOOK.LIVE.COM) I know Windows 7 and earlier use 1.1 but that's not the issue here, it's a web page, it doesn't have anything to do with the computer's OS. 0 -
Hi @Benjamin D. Nothing should be using TLSv1.1 or any other protocols besides TLSv1.2 as the new server doesn't accept those protocols. What I am concerned about is Microsoft continuing to use SSL or TLSv1.1 which causes connection issues. Is there an entry associated with these login attempts in /var/log/exim_mainlog? My assumption is that there will be an unknown protocol notification. If there is you may need to allow SSL as it's specifically disabled. It might also be helpful to get the following outputs from the old server: grep ssl_protocols /etc/dovecot/dovecot.conf grep openssl_options /etc/exim.conf0 -
Nothing should be using TLSv1.1 or any other protocols besides TLSv1.2
Facebook is still sending out mail using TLSv1. As is AOL it would seem. It would seem that nobody got the memo about TLSv1 and TLSv1.1 being insecure and/or that is mostly being ignored. I think eventually all of these SMH moments is going to make my head fall off. (Didn't really mean to throw this thread off topic, but thought it might be helpful to see that TLSv1 is still being somewhat widely used... even if that is a horrible idea)0 -
>> Is there an entry associated with these login attempts in /var/log/exim_mainlog? Yes, please read my post just directly above yours, please report again if that's not what you meant. The answer to your other 2 questions: [root@secure]# grep ssl_protocols /etc/dovecot/dovecot.conf ssl_protocols = TLSv1.2 [root@secure]# grep openssl_options /etc/exim.conf openssl_options = +no_sslv2 +no_sslv3 EDIT: Sorry! Those are the values from the *NEW* server. The old server is now unplugged. Can't go back baby! It's all forward from yesterday on. EDIT2: Tried to set WHM > Service Configuration > Mailserver Configuration > SSL Protocols = "TLSv1.1 TLSv1.2" instead of just "TLSv1.2" and it still does the same as described above: After 20 seconds, this shows up in the maillog: Jul 30 16:37:21 secure dovecot: pop3-login: Disconnected (no auth attempts in 20 secs): user=<>, rip=40.97.114.253, lip=[MY_SERVERS_IP], TLS handshaking: Disconnected, session= and Microsoft's connected account's page throws the error: "We were unable to reach your email provider. Please check your server settings, or try again later." Should I reboot POP3 and IMAP services after changing anything under WHM > Service Configuration > Mailserver Configuration ? My guess would be no, since WHM outputs this when I save: "Waiting for "dovecot" to restart "waiting for "dovecot" to initialize "finished." 0 -
You will want to enable everything except for SSLv2 and SSLv3 in Dovecot: cp -a /var/cpanel/conf/dovecot/main /var/cpanel/conf/dovecot/main.backup perl -pi -e "s/^ssl_protocols:.*/ssl_protocols: \"\!SSLv2 \!SSLv3\"/g" /var/cpanel/conf/dovecot/main /scripts/builddovecotconf /scripts/restartsrv_dovecot As @cPanelLauren says, using anything other than TLSv1.2 isn't recommended... but the world doesn't run on recommended. It runs on whatever the hell it wants to and ain't nobody gonna tell me what's secure. 0 -
@sparek-3 As per EDIT2 in my post directly before yours, it still doesn't work! I also copy/pasted your SH commands and retried. It still doesn't work and still does exactly precisely the same, after 20 seconds it times out and this shows up in maillog: Jul 30 16:47:46 secure dovecot: pop3-login: Disconnected (no auth attempts in 20 secs): user=<>, rip=40.97.114.253, lip=[MY_SERVERS_IP], TLS handshaking: Disconnected, session= Beginning to think it's not a SSL protocol issue. It might be related to CSF Firewall perhaps or a port that is not open maybe? But at the same time, why would maillog contain a trace of that Microsoft Azure server connection if the port was closed and either way, I know it's open because in maillog I see a tons of users logging in every second. PLEASE HALP. 0 -
Are you perhaps trying to use starttls on port 995? Port 995 is already secure and does not expect a starttls command. Port 110 would require a starttls command to initiate a secure connection. 0 -
I'm not trying to use STARTTLS. Have you ever used connected accounts on OUTLOOK.LIVE.COM (the web page, not the desktop app) ? The choices you get are: 1) NONE 2) SSL 3) TLS I tried them all earlier today. Even NONE fails which is almost impossible since "Allow Plaintext Authentication (from remote clients)" is set to "YES" on my server, but obviously, I'm aiming for having TLS working, ideally, which is what I've been testing over the last 4 hours, basically this whole thread. There is no STARTTLS encryption choice on OUTLOOK.LIVE.COM. Again, not talking about Microsoft Outlook on the Windows desktop. God, what were Microsoft engineers thinking when they chose to rename HOTMAIL.COM to OUTLOOK.COM damnit >.< EDIT: Wait, are you saying I should select TLS from the encryption dropdown menu and then revert the 995 port that Microsoft conveniently put in so that it becomes 110 instead? EDIT2: Doing what you seem to have suggested above (see EDIT1) immediately fails with this error: TLS negotiation failed with status "IllegalMessage". 0 -
I would use port 995 and select SSL. That should work. In this context, SSL means an encapsulated SSL connection (which is what port 995 is). TLS means (I think) STARTTLS, which is a way for POP3 to initiate a secure session on a non-encapsulated SSL port (i.e. port 110). But in other contexts SSL and TLS are used interchangeably. Which just increases the confusion. 0 -
It does NOT work with SSL either, I just tried it again to confirm. Let me try again with NONE and port 110. There is no reason why it would fail, because some older Windows 7 desktops use this (lack of) encryption in Outlook 2007 and 2010 right now and it works fine. EDIT: Success with Encryption: NONE on port 110. That's the only combination of settings that works currently. I'll put this in their stupid OUTLOOK.LIVE.COM account and be done for today. At least it will "work" albeit it's not gonna be secure at all, but it seems like what I'm asking (TLS) is IMPOSSIBLE between WHM and OUTLOOK.LIVE.COM anyway, at least for now. I'm kind of SUPER HAPPY to have it working and SUPER ANGRY for not having it working with any sort of encryption. But hey, at least there won't be any heartbleed issue there! 0 -
Hmm. I tried this on an outlook.com account - now whether or not if this is the same type of outlook account you are referring to, I don't know, but it's all I have access to. When I created a connected account in that outlook.com account and used: Incoming Server Port: 995 Encryption: SSL This worked as expected. When I used Incoming Port: 995 Encryption: TLS I got similar results as to what you are showing. When I used Incoming Port: 110 Encryption: TLS This worked as expected. This further begs a question: Do you have a valid certificate installed on whatever you have listed as Incoming (POP) Server? Perhaps that is the issue. I also noted that in my logs, all of these SSL/TLS connections are using TLSv1.2. So it would appear that the issue isn't related to TLS versions. (Although, again I'm using an account that you log in at outlook.com - if you are referring to something else, it's possible that it's using something different, but I would suspect that all of these are the same) 0 -
@sparek-3 Yes we're talking about thie same thing, you go on Outlook.com - Microsoft free personal email and you sign in and then you go to connected accounts in the settings menu at the top/right and you add a connected account. Yes all domains (and their subdomains) on this machine have a fully valid SSL certificate. I triple checked that today and it's all green. I also used an external online SSL checker to validate the chain and it's all good. I was skeptical when you guys mentioned earlier today that MS and FB still use 1.1 so I'm not shocked that they use 1.2 indeed. That would have been horrific if they didn't. Here's a run down of the same thing as what you tested, but for my new WHM server: Incoming Server Port: 995 Encryption: SSL = Time out error after 20 seconds, then error message on outlook.live.com config page: "We were unable to reach your email provider. Please check your server settings, or try again later." and maillog writes this: secure dovecot: pop3-login: Disconnected (no auth attempts in 20 secs): user=<>, rip=40.97.114.253, lip=[MY_SERVERS_IP], TLS handshaking: Disconnected, session= Incoming Port: 995 Encryption: TLS = Time out error after 20 seconds, then error message on outlook.live.com config page: "We were unable to reach your email provider. Please check your server settings, or try again later." and maillog writes this: secure dovecot: pop3-login: Disconnected (no auth attempts in 20 secs): user=<>, rip=40.97.114.253, lip=[MY_SERVERS_IP], TLS handshaking: Disconnected, session= Incoming Port: 110 Encryption: TLS = Instantaneous error message on outlook.live.com config page: TLS negotiation failed with status "IllegalMessage". Incoming Port: 110 Encryption: NONE Works as expected. 0 -
Hi @Benjamin D. I wanted to share what I found in testing this. I tried to add my own account to Outlook and discovered that I was receiving the following: Jul 31 13:05:41 server dovecot: imap-login: Disconnected (auth failed, 2 attempts in 8 secs): user=, method=PLAIN, rip=40.97.223.221, lip=MyIPAddress, session=<2Pa8O0tyBwsoYd/d> Jul 31 13:06:28 server dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=40.97.223.221, lip=MyIPAddress, TLS handshaking: SSL_accept() failed: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher, session= Jul 31 13:07:22 server dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=40.97.223.221, lip=MyIPAddress, TLS handshaking: SSL_accept() failed: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher, session= Jul 31 13:07:35 server dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=40.97.223.221, lip=MyIPAddress, TLS handshaking: SSL_accept() failed: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher, session=<7kUBQ0tyu28oYd/d> Jul 31 13:07:57 server dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=40.97.223.221, lip=MyIPAddress, TLS handshaking: SSL_accept() failed: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher, session=
40.97.223.221 is confirmed to be a Microsoft IP:NetRange: 40.74.0.0 - 40.125.127.255 CIDR: 40.74.0.0/15, 40.120.0.0/14, 40.112.0.0/13, 40.124.0.0/16, 40.125.0.0/17, 40.96.0.0/12, 40.76.0.0/14, 40.80.0.0/12 NetName: MSFT NetHandle: NET-40-74-0-0-1 Parent: NET40 (NET-40-0-0-0-0) NetType: Direct Assignment OriginAS: Organization: Microsoft Corporation (MSFT) RegDate: 2015-02-23 Updated: 2015-05-27 Ref: https://rdap.arin.net/registry/ip/40.74.0.0
In my case, this is telling me that Microsoft has no shared cipher suites with my server. In order to resolve this, you'd need to implement a cipher suite Microsoft shares. I was trying to get that information but it would appear that Outlook has decided to no longer connect to my server - my assumption is that I tried too many times to auth and triggered some protection on their side as there's no block on mine. Thanks!0 -
I didn't have any problems testing this. But perhaps my cipher list is not up to date with current cPanel values? My /etc/dovecot/dovecot.conf file contains: ssl_cipher_list = ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP ssl_protocols = !SSLv2 !SSLv3 And the log entry of my successful attempt from outlook.com shows: Jul 30 18:26:13 server dovecot: pop3-login: Login: user=, method=PLAIN, rip=132.245.25.132, lip=serverip:110, TLS, tls=TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits) I have more verbose logging enabled in my dovecot configuration: login_log_format_elements = user=<%u> method=%m rip=%r lip=%l:%a local_name=%{local_name} %c tls=%k This way it shows the port that is being connected to and the TLS version information. My connection from outlook is being made from the 132.245.0.0/16 network. @cPanelLauren and @Benjamin D. are showing this from a 40.* network, perhaps that is playing a role in this? 0 -
Hi @sparek-3 and @Benjamin D. @sparek-3 you gave me an idea that I wanted to test, I modified my SSL protocol and cipher suite to the following: [root@server ~]# egrep 'ssl_cipher_list|ssl_protocols' /etc/dovecot/dovecot.conf ssl_cipher_list = ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP ssl_protocols = !SSLv2
And I was then able to connect my account:Jul 31 14:52:40 server dovecot: imap-login: Login: user=, method=PLAIN, rip=40.97.223.221, lip=MyIPAddress, mpid=9095, TLS, session=<8nXGukxyzDcoYd/d> Jul 31 14:52:40 server dovecot: imap(test@mydomain.tld): Connection closed (CAPABILITY finished 0.529 secs ago) in=21, out=860, bytes=21/860 Jul 31 14:52:42 server dovecot: imap-login: Login: user=, method=PLAIN, rip=40.97.223.221, lip=MyIPAddress, mpid=9098, TLS, session=<5V/qukxyWkwoYd/d> Jul 31 14:52:49 server dovecot: imap(test@mydomain.tld): Connection closed (CAPABILITY finished 7.164 secs ago) in=21, out=860, bytes=21/860 Jul 31 14:53:37 server spamd[6157]: spamd: connection from localhost [::1]:41876 to port 783, fd 5
Now I want to point out that I do not recommend this course of action but if it's necessary to have the accounts connected this way you could make the modifications I did.0 -
Thanks for sharing your test results concerning my case, god, I MEAN @cPanelLauren ;-) So, it kind of confirms what we're thinking since yesterday: MS uses a specific cipher suite that doesn't come by default on a vanilla/default WHM 72.0 installation. Thanks @sparek-3 it's very nice of you to provide this. The most important bit of information in this whole thread is: "AES256-GCM-SHA384". That's my WHM server's cipher suite: ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 I'm not savvy enough to tell if your cipher (AES256-GCM-SHA384) is part of mine. I see this search term is part of the string, but it's not EXACTLY :AES256-GCM-SHA384: so can this be the problem? @sparek-3 Would you be so kind as to post your entire cipher suite string from your server, the one that successfully connects with OUTLOOK.LIVE.COM connected accounts? ** CAN SOMEBODY AT CPANEL PLEASE MOVE OR CP "Service Configuration > Mailserver Configuration" to "Email > Mailserver Configuration" DAMNIT... I always lose 20 seconds looking for this EVERY SINGLE TIME. User experience goes down every time I'm looking for this. 0 -
Hi @Benjamin D. Thanks for sharing your test results concerning my case, god, I MEAN @cPanelLauren ;-)
Haha if only......:rolleyes: I did a bit more testing and moved the ssl_protocols back to TLSv1.2 only but keeping the cipher suite @sparek-3 is using:[root@server ~]# egrep 'ssl_cipher_list|ssl_protocols' /etc/dovecot/dovecot.conf ssl_cipher_list = ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP ssl_protocols = TLSv1.2
This continued to work (i removed the account and readded it) AES256-GCM-SHA384 is a part of yours but not quite as it's ECDHE-ECDSA-AES256-GCM-SHA384 though both are part of the TLSv1.2 cipher suites. I did find if I modified my own cipher suites to include it specifically:[root@server ~]# egrep 'ssl_cipher_list|ssl_protocols' /etc/dovecot/dovecot.conf ssl_cipher_list = AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 ssl_protocols = TLSv1.2
It worked - I was able to add my account again without issue - so essentially all you need to do is add AES256-GCM-SHA384 to your list of cipher suites in mailserver configuration.CAN SOMEBODY AT CPANEL PLEASE MOVE OR CP "Service Configuration > Mailserver Configuration" to "Email > Mailserver Configuration" DAMNIT... I always lose 20 seconds looking for this EVERY SINGLE TIME. User experience goes down every time I'm looking for this.
TBH I use the search bar every time I want to find something rather than click through. I know they're working on implementing some streamlining of the UI though it won't be out for a while. Thanks!0 -
OK SO BACK TO THE ISSUE PLEASE: So imagine that my current WHM cipher suite currently = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 Are you suggesting that I change this string to: AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 (notice the added part in bold/black) 0 -
Are you suggesting that I change this string to: AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
That's exactly what I'm saying. Looks like that was the resolution for me, sorry it ended up so convoluted I was testing as I was going and wanted you guys to see all the configurations I had tried. I am assuming AES256-GCM-SHA384 is a weaker cipher suite and was not included in the versions we distributed when re-vamping these.0 -
(Going slightly off-topic here) Would it be a good idea for cPanel to publish what cipher suites they recommend for all services (dovecot, exim, apache, ftp)? Because it's my understanding that if you update cPanel, it keeps your current cipher suites and TLS versions. And while I agree with that action, it might be beneficial to know what cPanel is recommending and using for fresh installs, so that those of us that want to update to respectable cipher suites can do so. (or is this published some where that I don't know about?) 0 -
Because it's my understanding that if you update cPanel, it keeps your current cipher suites and TLS versions. And while I agree with that action, it might be beneficial to know what cPanel is recommending and using for fresh installs, so that those of us that want to update to respectable cipher suites can do so
This is the behavior it exhibits now which is why @Benjamin D. only experienced the issue when moving to a new server. We do have the documentation here which details the current cipher suites: How to Adjust Cipher Protocols - cPanel Knowledge Base - cPanel Documentation0 -
Hmm, that document only gives a cipher suite for cPanel/WHM/Webmail. Does it give the recommended cipher suite to use for Dovecot, Exim, Apache, and FTP? It tells you how to change them. But it doesn't tell you what to change them too as recommended by cPanel. Or am I missing that information as I skim over this document? 0 -
It gives you the suites: ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
They're in a dropdown - seems it's suggesting the same cipher suites for everything. It also notes a specific set of suites for Microsoft.0 -
Wait for it... :confused: ... :eek: SU--F**KIN--CCESS !!! :-D:-D:-D:-D IT WORKS with cipher: AES256-GCM-SHA384 added to my SSL cipher suite! Why isn't this cipher part of the default WHM 72.0 set tough?! Microsoft is a HUGE player and altough not a big percentage of my customers actually use connected accounts, I cannot believe I'm the only one with 72.0 having this default cipher suite not containing AES256-GCM-SHA384 and who has had to jump through so many loops to get it working. SOMEBODY AT CPANEL, PLEASE ADD AES256-GCM-SHA384 TO THE DEFAULT CIPHER SUITE. After 6 days of hair pulling, my server migration is now completed. I would have never imagined the process to be so rough and complicated. Thank you so much @cPanelLauren and @sparek-3 for this solution. AT LAST it's working WOW! 0 -
Hi @Benjamin D. I'm really happy this is working for you now. Unfortunately, I don't believe it would be added, this cipher suite is considered a legacy suite and is only used for compatibility with legacy libraries. 0 -
Kind of goes back to my original point. Security is only as good as least common denominator. Yes, stronger ciphers and secure versions of TLS should be used... but when Microsoft and Facebook and all of the other major players refuse to go along with what is better and more secure, then we all have to dip down to their level. Is there any wonder why security on the Internet is failing? 0 -
Yep 100% agreed @sparek-3 This conversation reminds me of Google pushing Adobe Flash to its users, silently, within the Chrome browser while Apple completely disabled it on iOS a decade ago and Firefox constantly persuading its users to stop using this P.O.S. by disabling every single version Adobe releases like a day after it's out lol XD Or that customer who runs a shop that uses brand new management software that REQUIRES INTERNET EXPLORER, yes you read that right in 2018, IT REQUIRES ACTIVEX COMPONENTS TO RUN. Last time I went there, I showed them how to run that P.O.S. inside vmware and told them it's the only way it can run, because Internet Explorer does not exist anymore under W10. They did not understand the part where I tried to explain to them that their BRAND NEW piece of sh* I mean piece of software will NOT run on an iPad or an Android tablet. Nope. But it will run on an old W8.1 Surface pile of crap that they got for nearly free from a frustrated student who purchased this back 4 years ago and soon discovered that he could not install any application on it, except what's coming out of the Microsoft Store. 0
Please sign in to leave a comment.
Comments
29 comments