My PCI scans are failing on my win 2012 R2 server because of this.
Here is the list of medium strength SSL ciphers supported by the remote server : Medium Strength Ciphers (> 64-bit and < 112-bit key) TLSv1 DES-CBC3-SHA Kx=RSA Au=RSA Enc=3DES-CBC(168) Mac=SHA1
They told me it was this one
DES-CBC3-SHA
I believe Microsoft refers to it as
TLS_RSA_WITH_3DES_EDE_CBC_SHA
I would prefer to turn this off using the registry.
Anyone know how?
Thanks.
I figured it out.
On win 2012 r2 all you have to do is add this reg key.
It takes effect immediately.
REGEDIT4
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168]
"Enabled"=dword:00000000
I verified it works using:
https://www.ssllabs.com/ssltest/analyze.html
Related
I've been trying to use Chilkat library to play around and learn about using Microsoft Graph APIs but it seems I keeps getting TLS errors (connectFailReason 109) with even the simplest GETs and POSTs. This is what a typical log looks like:
ChilkatLog:
QuickGetSb:
DllDate: May 29 2021
ChilkatVersion: 9.5.0.87
UnlockPrefix: XXXXXXXXXXXXXXXX
Architecture: Little Endian; 32-bit
Language: C++ Builder / clang / 32-bit
VerboseLogging: 0
Component successfully unlocked using purchased unlock code.
url: https://graph.microsoft.com/v1.0/users
httpRequestStr:
a_quickReq:
quickHttpRequest:
httpVerb: GET
url: https://graph.microsoft.com/v1.0/users
openHttpConnection:
Opening connection directly to HTTP server.
httpHostname: graph.microsoft.com
httpPort: 443
tls: True
socket2Connect:
connect2:
connectImplicitSsl:
clientHandshake:
clientHandshake2:
ProcessHelloRetryRequest:
readHandshakeMessages:
WindowsError: An existing connection was forcibly closed by the remote host.
WindowsErrorCode: 0x2746
maxToReceive: 5
Failed to receive data on the TCP socket
Failed to read beginning of SSL/TLS record.
b: 0
dbSize: 0
nReadNBytes: 0
idleTimeoutMs: 60000
--readHandshakeMessages
--ProcessHelloRetryRequest
--clientHandshake2
--clientHandshake
Client handshake failed. (3)
--connectImplicitSsl
connectFailReason: 109
ConnectFailReason: 109
--connect2
--socket2Connect
connect: Socket fatal error.
--openHttpConnection
--quickHttpRequest
--a_quickReq
--httpRequestStr
Failed.
--QuickGetSb
--ChilkatLog
The library is not the very latest version but it isn't TOO old (about a year and a half - version 9.5.0.86). I didn't want to upgrade just yet because I have some "live" projects using this dev box (and this is just a "learning journey") so I was wondering if anyone can tell me whether the library version is the most likely issue or whether, perhaps, I'm missing some simple settings in the CkHttp object - the only thing I really do with it is set the auth token (which seems to have been retrieved correctly judging from the logs I output.
The actual API calls are pretty straightforward - mostly simple (slightly modified) examples from Chilkat website. But even the simplest http.quickGetStr("https://graph.microsoft.com/v1.0/me"); fails with a log similar to the above.
So, if anyone can suggest any properties to set to ckHttp to solve this issue (or confirm that library needs to be upgraded to access graph.microsoft.com - if, indeed, that is the case) - I would greatly appreaciate it.
Marko
This problem is already fixed. Contact support#chilkatsoft.com to get a pre-release build for v9.5.0.92.
I have very basic C++ application that uses openssl library. Application sends request to server and the list of ciphersuites have to be the next:
4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53
Using SSL_set_cipher_list and SSL_set_ciphersuites I am setting list of ciphers. But when I use next list:
TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
I am getting 4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53-255. But I cannot understand where 255 in the end come from ? It shouldn't appear.
255 is a special cipher suit identifier. Reading RFCs when you deal with security is always useful.
RFC5746
3.3. Renegotiation Protection Request Signaling Cipher Suite Value
Both the SSLv3 and TLS 1.0/TLS 1.1 specifications require implementations to ignore data following the ClientHello (i.e., extensions) if they do not understand it. However, some SSLv3 and TLS 1.0 implementations incorrectly fail the handshake in such a case. This means that clients that offer the "renegotiation_info" extension may encounter handshake failures. In order to enhance compatibility with such servers, this document defines a second signaling mechanism via a special Signaling Cipher Suite Value (SCSV) "TLS_EMPTY_RENEGOTIATION_INFO_SCSV", with code point {0x00, 0xFF}. This SCSV is not a true cipher suite (it does not correspond to any valid set of algorithms) and cannot be negotiated. Instead, it has the same semantics as an empty "renegotiation_info" extension, as described in the following sections. Because SSLv3 and TLS implementations reliably ignore unknown cipher suites, the SCSV may be safely sent to any server. The SCSV can also be included in the SSLv2 backward compatible CLIENT-HELLO (see Appendix E.2 of [RFC5246]).
Now you know the name TLS_EMPTY_RENEGOTIATION_INFO_SCSV and you can try to exclude it. But this may be not working.
I need to install USB CDC driver (com port) to customers pc so my c++ mfc application works correctly. On windows 8 & 10 the driver is pre-installed, the problem is older verions of windows.
I have the driver from silabs, there is .cat, .inf and .exe files. After opening the installer - it just says "Silicon Laboratories. Inc. (usbser) Ports (03/26/2014 6.1.7601.17514) - Ready to use" after confirming the terms, nothing else.
I tried this but there is no usbser.sys or something like that in the list. And also this but nothing like "USB\VID_1BA4&PID_0002" (which I found in .inf file) wasn't found. I also tried to search for ClassGUID (4D36E978-E325-11CE-BFC1-08002BE10318) & class=ports in regedit. It's always found the same things, that's probably not what I'm looking for.
What should I look for? What parameter is important? Thanks.
.inf file
[Version]
Signature="$WINDOWS NT$"
Class=Ports
ClassGUID={4D36E978-E325-11CE-BFC1-08002BE10318}
Provider=%SILICONLABS%
DriverVer=03/26/2014,6.1.7601.17514
CatalogFile=SiLabs-CDC.cat
[Manufacturer]
%SILICONLABS%=DeviceList, NT, NTAMD64, NTIA64
;------------------------------------------------------------------------------
[DeviceList]
%CDCDEVICE_1BA4_0002%=DriverInstall,USB\VID_1BA4&PID_0002
%CDCDEVICE_2544_0003%=DriverInstall,USB\VID_2544&PID_0003
%CDCDEVICE_10C4_0003%=DriverInstall,USB\VID_10C4&PID_0003
%CDCDEVICE_2544_0008_02%=DriverInstall,USB\VID_2544&PID_0008&MI_02
%CDCDEVICE_10C4_0008_02%=DriverInstall,USB\VID_10C4&PID_0008&MI_02
[DeviceList.NT]
%CDCDEVICE_1BA4_0002%=DriverInstall,USB\VID_1BA4&PID_0002
%CDCDEVICE_2544_0003%=DriverInstall,USB\VID_2544&PID_0003
%CDCDEVICE_10C4_0003%=DriverInstall,USB\VID_10C4&PID_0003
%CDCDEVICE_2544_0008_02%=DriverInstall,USB\VID_2544&PID_0008&MI_02
%CDCDEVICE_10C4_0008_02%=DriverInstall,USB\VID_10C4&PID_0008&MI_02
[DeviceList.NTAMD64]
%CDCDEVICE_1BA4_0002%=DriverInstall,USB\VID_1BA4&PID_0002
%CDCDEVICE_2544_0003%=DriverInstall,USB\VID_2544&PID_0003
%CDCDEVICE_10C4_0003%=DriverInstall,USB\VID_10C4&PID_0003
%CDCDEVICE_2544_0008_02%=DriverInstall,USB\VID_2544&PID_0008&MI_02
%CDCDEVICE_10C4_0008_02%=DriverInstall,USB\VID_10C4&PID_0008&MI_02
[DeviceList.NTIA64]
%CDCDEVICE_1BA4_0002%=DriverInstall,USB\VID_1BA4&PID_0002
%CDCDEVICE_2544_0003%=DriverInstall,USB\VID_2544&PID_0003
%CDCDEVICE_10C4_0003%=DriverInstall,USB\VID_10C4&PID_0003
%CDCDEVICE_2544_0008_02%=DriverInstall,USB\VID_2544&PID_0008&MI_02
%CDCDEVICE_10C4_0008_02%=DriverInstall,USB\VID_10C4&PID_0008&MI_02
;------------------------------------------------------------------------------
[DriverInstall]
Include=mdmcpq.inf
CopyFiles=FakeModemCopyFileSection
AddReg=SerialPropPageAddReg
[DriverInstall.Services]
Include=mdmcpq.inf
AddService = usbser, 0x00000002, DriverServiceInst
[DriverServiceInst]
DisplayName=%SERVICE%
ServiceType=1
StartType=3
ErrorControl=1
ServiceBinary=%12%\usbser.sys
[SerialPropPageAddReg]
HKR,,EnumPropPages32,,"MsPorts.dll,SerialPortPropPageProvider"
;------------------------------------------------------------------------------
[Strings]
SILICONLABS = "Silicon Laboratories, Inc."
CDCDEVICE_1BA4_0002 = "Silicon Labs CDC Serial port"
CDCDEVICE_2544_0003 = "Silicon Labs CDC Serial port"
CDCDEVICE_10C4_0003 = "Silicon Labs CDC Serial port"
CDCDEVICE_2544_0008_02 = "Silicon Labs CDC Serial port"
CDCDEVICE_10C4_0008_02 = "Silicon Labs CDC Serial port"
SERVICE = "USB CDC Serial Port Driver"
The code sample you use is Enumerating All Device Drivers in the System(loaded drivers).
I test with a FTDI USB-to-UART device. With the device attached to PC (driver loaded in memory) I can list related drivers like below, otherwise I can't.
So trying to attach the USB CDC device and try again.
Update based on comment: "But where I can find if the driver is already signed or not, that's the question."
Right click the *.sys file of the driver and check the digital signatures tab.
We have some SSL communication using Boost asio. Connecting and communication works fine, but now we'd like to show the actual TLS version and cipher used by the connection.
The Boost asio objects we use for the SSL connection are defined like this:
typedef boost::asio::ssl::stream<boost::asio::ip::tcp::socket> ssl_socket;
boost::shared_ptr<ssl_socket> m_psslsocket;
boost::asio::ssl::context* m_pcontext;
It looks like Boost asio doesn't really have an interface to query the connection for the cipher once it's set up.
I can get the OpenSSL SSL_CTX* pointer by calling this:
SSL_CTX* ctx = pContext->impl();
Or the OpenSSL SSL* by calling this:
m_psslsocket->native_handle()
But from the OpenSSL documentation I can't figure out how to get the used cipher and TLS version from this.
OpenSSL documentation says:
SSL_client_version() returns the numeric protocol version advertised by the client in the legacy_version field of the ClientHello when initiating the connection. Note that, for TLS, this value will never indicate a version greater than TLSv1.2 even if TLSv1.3 is subsequently negotiated. SSL_get_version() returns the name of the protocol used for the connection. SSL_version() returns the numeric protocol version used for the connection. They should only be called after the initial handshake has been completed. Prior to that the results returned from these functions may be unreliable.
So the answer is:
SSL_get_version(SSL*)
This question already has an answer here:
SSL operation failed with code 1: dh key too small
(1 answer)
Closed 6 years ago.
I am programming a "Terminal" in C++ to which a client can connect using SSL to encrypt the connection. I use Boost::asio to handle the sockets and SSL.
I am starting the SSL-Context like this:
boost::asio::ssl::context context_(io_service_, boost::asio::ssl::context::tlsv1);
As you can see, I set the SSL-Version to TLSv1.
This are the context-options:
context_.set_options(boost::asio::ssl::context::default_workarounds
| boost::asio::ssl::context::no_sslv2
| boost::asio::ssl::context::single_dh_use);
context_.use_certificate_chain_file("CERTS/server.crt");
context_.use_private_key_file("CERTS/server.key", boost::asio::ssl::context::pem);
context_.use_tmp_dh_file("CERTS/dh512.pem");
When I now conntect to my server with openssl s_client -connect localhost:8000 -tls1 the handshake fails on the serverside with the error:
"sslv3 alert handshake failure"
Also, I noticed a strange line on the client side:
"140030998197920:error:14082174:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3329:"
What does this mean? Did I make a mistake when I created the certificate? I did it exactly as described in the answer to this question.
context_.use_tmp_dh_file("CERTS/dh512.pem");
... dh key too small:s3_clnt.c:3329:"
You are using a DH key of only 512 bit. Such keys are considered too weak and the handshake will fail with newer versions of TLS libraries. You should better use a 2048 bit DH key instead or even better use ciphers with ECDHE.
For more details on the problem see Logjam Attack.