Bug 1549242

Summary:	SSL connection failure: The Diffie-Hellman prime sent by the server is not acceptable (not long enough).
Product:	[Fedora] Fedora	Reporter:	Craig <candrews>
Component:	openconnect	Assignee:	David Woodhouse <dwmw2>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	28	CC:	bugzilla, dwmw2, elreydetodo, nmavrogi
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-10-27 10:14:14 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Craig 2018-02-26 19:43:03 UTC

Description of problem:

Trying to connect to the corporate VPN with a weak DH prime results in an error.

Version-Release number of selected component (if applicable):
openconnect-7.08-5.fc28.x86_64

How reproducible:
Always (when connecting to a VPN server that is insecure)

Steps to Reproduce:
1. $ openconnect <redacted>

Actual results:
POST https://<redacted>/
Connected to <redacted>:443
SSL negotiation with <redacted>
SSL connection failure: The Diffie-Hellman prime sent by the server is not acceptable (not long enough).
Failed to open HTTPS connection to <redacted>
Failed to obtain WebVPN cookie

Expected results:
Working connection

Additional info:
This issue is new in Fedora 28 (Fedora 27 works fine).

Note that I agree that the VPN sever is in the wrong here. But, IT departments are super slow and not exactly security conscious - especially when no Windows or Mac users are impacted. The IT department is not likely to care that the one Linux user can no longer connect to the VPN, even if the VPN server is a security liability. So, there needs to be a way to override this behavior and allow the connection to be established.

Comment 1 Nikos Mavrogiannopoulos 2018-02-27 10:37:28 UTC

That's because of:
https://fedoraproject.org/wiki/Changes/StrongCryptoSettings

Comment 2 bugzilla 2018-03-05 09:48:58 UTC

Just faced the same problem. Upgraded yesterday to F28 for testing purposes, now i can not connect to the VPN of the company anymore. Don't know if its easy for the IT of that company to upgrade the DH key to 2k (or better more). 

I guess this is not a bug, it is more kind of a feature. When the server is badly configured (low security), it makes sense to block the connection instead of silently allowing it.

Have to use Windows 7 now to connect to the VPN :X

Comment 3 Nikos Mavrogiannopoulos 2018-03-05 10:01:01 UTC

You can work around it as 'update-crypto-policies --set LEGACY'

Comment 4 bugzilla 2018-03-05 10:11:28 UTC

Thanks, its working :)

Comment 5 David Woodhouse 2018-03-06 10:15:08 UTC

Is there a way the error handling can be improved here. Should OpenConnect respond to GNUTLS_E_DH_PRIME_UNACCEPTABLE by printing some message about "check your distribution's crypto policies" ?

Comment 6 Nikos Mavrogiannopoulos 2018-03-06 12:13:31 UTC

It is not only an issue on openconnect. I'm considering lowering that value:
https://gitlab.com/redhat-crypto/fedora-crypto-policies/merge_requests/16

Comment 7 Fedora Update System 2018-03-06 12:42:39 UTC

crypto-policies-20180306-1.gitaea6928.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-b849029629

Comment 8 Fedora Update System 2018-03-08 15:25:51 UTC

crypto-policies-20180306-1.gitaea6928.fc28, openssh-7.6p1-7.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-b849029629

Comment 9 Fedora Update System 2018-03-30 12:42:48 UTC

crypto-policies-20180306-1.gitaea6928.fc28, openssh-7.6p1-7.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.