Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ Library support » U++ Core » Any good reason why SSL support is hardcoded to SSLv3 usage?
Any good reason why SSL support is hardcoded to SSLv3 usage? [message #43813] Fri, 24 October 2014 17:57 Go to next message
steffen is currently offline  steffen
Messages: 38
Registered: May 2007
Location: Denmark
Member

Hi,

I just made little test with HttpRequest and found that I could not connect to any of our secure servers.
SSLv3 was deprecated 15 years ago, and is now proven vulnerable to the poodle attack.

TcpSocket::SSLImp::Start() is hardcoded to use SSLv3:
	if(!context.Create(socket.mode == CONNECT ? const_cast<SSL_METHOD *>(SSLv3_client_method())
	                                          : const_cast<SSL_METHOD *>(SSLv3_server_method()))) {
		SetSSLError("Start: SSL context.");
		return false;
	}

Changing the methods to TLSv1_2 allowed my little test to connect with our servers:
	if(!context.Create(socket.mode == CONNECT ? const_cast<SSL_METHOD *>(TLSv1_2_client_method())
	                                          : const_cast<SSL_METHOD *>(TLSv1_2_server_method()))) {
		SetSSLError("Start: SSL context.");
		return false;
	}

In my case it works with TLSv1, TLSv1_1 and TLSv1_2.
Are there any plans on making the protocol selectable or not?
I can try to make a solution, adding a member variable like "SSL_METHOD *sslMethod;" and use it if it is not null otherwise fallback to current code.

There was another report on a similar request earlier this year:
http:// www.ultimatepp.org/forums/index.php?t=msg&th=8408&go to=42367&#msg_42367
Re: Any good reason why SSL support is hardcoded to SSLv3 usage? [message #43822 is a reply to message #43813] Wed, 29 October 2014 09:57 Go to previous message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
steffen wrote on Fri, 24 October 2014 17:57
Hi,

I just made little test with HttpRequest and found that I could not connect to any of our secure servers.
SSLv3 was deprecated 15 years ago, and is now proven vulnerable to the poodle attack.

TcpSocket::SSLImp::Start() is hardcoded to use SSLv3:
	if(!context.Create(socket.mode == CONNECT ? const_cast<SSL_METHOD *>(SSLv3_client_method())
	                                          : const_cast<SSL_METHOD *>(SSLv3_server_method()))) {
		SetSSLError("Start: SSL context.");
		return false;
	}

Changing the methods to TLSv1_2 allowed my little test to connect with our servers:
	if(!context.Create(socket.mode == CONNECT ? const_cast<SSL_METHOD *>(TLSv1_2_client_method())
	                                          : const_cast<SSL_METHOD *>(TLSv1_2_server_method()))) {
		SetSSLError("Start: SSL context.");
		return false;
	}

In my case it works with TLSv1, TLSv1_1 and TLSv1_2.
Are there any plans on making the protocol selectable or not?
I can try to make a solution, adding a member variable like "SSL_METHOD *sslMethod;" and use it if it is not null otherwise fallback to current code.

There was another report on a similar request earlier this year:
http:// www.ultimatepp.org/forums/index.php?t=msg&th=8408&go to=42367&#msg_42367


Interestingly, I have hit the same issue too 14 days ago, so we are now using SSLv23_client_method/SSLv23_server_method, which according to docs should cover TLS methods as well and downgrade if not available.

Mirek
Previous Topic: Problem with copy construction of std::vector from Upp::Vector
Next Topic: Missing GetTickCount64
Goto Forum:
  


Current Time: Fri Apr 19 03:07:07 CEST 2024

Total time taken to generate the page: 0.10663 seconds