User who has authorized TLS certificate only able to connect to Open-sip server from application (Android and iOS).
What we need to change in config file for only TLS connection to Open-sip server.
You can configure the TLS certificate information in opensips.cfg file
tls_certificate="/usr/local/etc/opensips/tls/glob/glob-cert.pem"
tls_private_key="/usr/local/etc/opensips/tls/glob/glob-privkey.pem"
tls_ca_list="/usr/local/etc/opensips/tls/glob/glob-calist.pem"
## turn on the strictest and strongest authentication possible
tls_verify_client = 1
tls_require_client_certificate = 1
tls_method = TLSv1
tls_verify_client = 1 will ensure the client with authorized certificate configured in tls_ca_list file
Can you try uncommenting the line of startTLS from config file and make it true as a value?
It should work!
Also make sure that your Android and iOS clients are configured to accept TLS connections(though most of the time it's default behaviour).
Related
I am trying to implement peer certificate validation in node.js with express.
In the production i receive error: EE certificate key too weak.
How can i change it to support the weak key?
I don't want to ignore it in the code level, because if i am doing that it does not check the CA at all.
In the development server, if i remove the matching CA certificate i receive UNABLE_TO_VERIFY_LEAF_SIGNATURE, while in the production server i receive "EE certificate key too weak" - it does not check it at all.
In the development server it is working correctly, but in the production server i receive the error.
I cannot change the certificate on the client devices, so i must support the weak key.
https.createServer({
key: getFile(config.get("ssl_certificate.key")),
cert: getFile(config.get("ssl_certificate.cert")),
ca: [
getCACertFile('ca-crt.pem'), //some certificates
],
requestCert: true,
rejectUnauthorized: false
},app)
In req.socket.authorizationError, i expect to receive null.
In the development server i receive null, but in the production server i receive "EE certificate key too weak"
stderrs:
error: failed to start server: Error: error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak
at Object.createSecureContext (_tls_common.js:135:17)
at Server (_tls_wrap.js:873:27)
at new Server (https.js:62:14)
at Object.createServer (https.js:85:10)
Node v10.0.0 Release News
Dependencies
V8 has been updated to 6.6. [9daebb48d6]
OpenSSL has been updated to 1.1.0h. [66cb29e646]
If you are using Node.js>=10.0.0, it will raise the exception if certs are encrypted by sha1 or md5.
Generate new certs encrypted by sha256 will fix the question on Server.
But in your case, since the certs has been used for devices to connect to server, you can simply use Node.js<10.0.0 (eg:v8.x) to start the server.
Besides, suggest to use nvm to control versions of Node.js.
nvm use v8.x.x
node server.js
Two aspects of your typical SSL cert immediately jump to one's mind: RSA key length, and the hash algorithm. The recipe to accept the cert might differ based on which one is weak.
Check the cert properties, under Siganture Algorithm. Is it sha1RSA by any chance? If so, search for enabling SHA1 support.
Check the public key. How many bits in it? Is it less than 1024? Then search for minimum RSA key length setting.
I have a simple TLS client in python that connects to TLS servers. I do not have control over the servers. I need a fresh TLS handshake with each server even if I visited it recently.
1) Do non-browser TLS clients such as the following python client perform session resumption by default?
2) How can I know if they do or do not? How can I disable session resumption if it is performed in the background?
Please note that I create a new socket for each new domain that I connect to.
import socket, ssl
context = ssl.SSLContext()
context.verify_mode = ssl.CERT_NONE
context.check_hostname = False
mycipher = "DHE-RSA-AES128-SHA"
context.set_ciphers(mycipher)
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
domain = "google.com"
mySocket = context.wrap_socket(sock, server_hostname = domain)
mySocket.connect((domain, 443))
mySocket.close()
This is a difficult but interesting question. And you did use the appropriate term TLS which brings me joy ;-)
First, see that session resumption has changed in TLS1.3, so this may impact things in the future for you (at least the naming, pre TLS1.3 this feature speaks more about sessions and tickets while TLS1.3 prefers to speak about a pre shared key): https://timtaubert.de/blog/2017/02/the-future-of-session-resumption/
Now about your questions:
1) Do non-browser TLS clients such as the following python client perform session resumption by default?
Python documentation at https://docs.python.org/3.7/library/ssl.html does not say anything about "resumption"; I would posit if it says nothing about it it is not doing it at all. But it does speak up about "cache" which could be a synonym.
In fact you can note at https://docs.python.org/3.7/library/ssl.html#ssl.SSLSession that the session has the following attributes: ticket_lifetime_hint and has_ticket; this should be related to resumption.
Now look at https://docs.python.org/3.7/library/ssl.html#ssl.SSLContext.options and if you browse all possible values, you get:
ssl.OP_NO_TICKET
Prevent client side from requesting a session ticket.
So my assumption in 1) may be wrong and you have session resumption by default. You should disable it using the above option
(On the contrary) it seems to exist in PyOpenSSL (vs just stock ssl) because there is even one question here on how to disable this feature for that library: How to disable session resumption in pyOpenSSL?
Empirically you could try to discover that by running your application in such a way that it connects twice in close time to same endpoint and see what kind of TLS messages are exchanged. For example in TLS 1.3 (should be similar with other versions, but some name may change), a fresh handshake starts with ClientHello/ServerHello where a resumption starts with the same messages but with a pre_shared_key extension. Its presence will show TLS resumption. In TLS 1.2 the client would send a SessionTicketextension during resumption handshake.
2) How can I know if they do or do not? How can I disable session resumption if it is performed in the background?
If I am right about the above, make sure to use ssl.OP_NO_TICKET in ths SSL context object. Otherwise it is OP_ALL by default which is a bag of various options designed to maximize interoperability but the content may change depending on your Python version and the underlying OpenSSL library used.
If your session has the has_ticket attribute filled I guess it uses TLS resumption or is set up to use it.
1) Do non-browser TLS clients such as the following python client perform session resumption by default?
By default the python tls/ssl libraries do not perform session resumption.
2) How can I know if they do or do not? How can I disable session resumption if it is performed in the background?
You can verify that session resumption has not happened with the following code:
import socket
import ssl
hostname = 'www.stackoverflow.com'
context = ssl.create_default_context()
# Create a new socket, then create a secure socket
sock = socket.create_connection((hostname, 443))
ssock = context.wrap_socket(sock, server_hostname=hostname)
# Was the TLS Session re-used?
print(ssock.session_reused) # False
TLS session resumption can be enabled by using last ssl session.
hostname = 'google.com'
port = 443
resource = '/'
context = ssl.SSLContext(ssl.PROTOCOL_TLS)
sock = socket.create_connection((hostname, port))
ssock = context.wrap_socket(sock, server_hostname=hostname)
#send - receive
ssr = ssock.session
print(ssock.session_reused) # False
ssock.close()
sock = socket.create_connection((hostname, port))
ssock = context.wrap_socket(sock, server_hostname=hostname, session=ssr)
#send - receive
print(ssock.session_reused) # True , if server support it
ssock.close()
I have the following mosquitto.conf but when internet goes out, it does not buffer and send to AWS IoT when internet comes back.
Questions:
What have I done wrong with the mosquitto config that the offline buffering is not working as expected?
I am thinking of writing my own bridge on NodeJS. Any recommendation of NodeJS MQTT library that supports offline buffering?
Thank you!
pid_file /var/run/mosquitto.pid
persistence true
persistence_location /var/lib/mosquitto/
log_dest file /var/log/mosquitto/mosquitto.log
# =================================================================
# Bridges to AWS IOT
# =================================================================
# AWS IoT endpoint, use AWS CLI 'aws iot describe-endpoint'
connection awsiot
address aws.iot.us-west-2.amazonaws.com:8883
# Specifying which topics are bridged
topic outTopic out 1
# Setting protocol version explicitly
bridge_protocol_version mqttv311
bridge_insecure false
# Bridge connection name and MQTT client Id,
# enabling the connection automatically when the broker starts.
cleansession true
clientid bridgeawsiot
start_type automatic
notifications false
log_type all
cafile /home/pi/ca.crt
keyfile /home/pi/server.key
certfile /home/pi/server.crt
tls_version tlsv1
# =================================================================
# Certificate based SSL/TLS support
# -----------------------------------------------------------------
#Path to the rootCA
bridge_cafile /home/pi/rootCA.cer
# Path to the PEM encoded client certificate
bridge_certfile /home/pi/bridge.cert.pem
# Path to the PEM encoded client private key
bridge_keyfile /home/pi/bridge.private.key
The cleansession true in your bridge config will mean that no messages are queued when the bridge is down.
I use Tyrus webSocket implementation to connect to the server from my JavaFX application. When I try to establish connection over SSL I get this error: javax.net.ssl.SSLException: SSL handshake error has occurred - more data needed for validating the certificate
I tried to use a dummy certificate and host verification as described in Disable Certificate Validation in Java SSL Connections but to no avail.
There is also not much information on Tyrus documentation.
I simply don't know what to do!
P.S. For what it's worth I managed to get around this issue by using Grizzly client
//final WebSocketContainer container = ContainerProvider.getWebSocketContainer();
final ClientManager client = ClientManager.createClient();
URI uri = URI.create(this.uri + "?" + System.currentTimeMillis());
session = client.connectToServer(this, uri);
It sounds like you need to install a certificate chain. I believe you can import the signing certificate using keytool -import. Have you setup the certificate store?
I am implementing SSL server using boost::asio.
The context initialization is shown in below code
boost::asio::ssl::context_base::method SSL_version =
static_cast<boost::asio::ssl::context_base::method>(param_values[ID_PROTOCOL_VERSION].int32_value);
// load certificate files
boost::shared_ptr<boost::asio::ssl::context> context_ = boost::shared_ptr<boost::asio::ssl::context>(
new boost::asio::ssl::context(SSL_version));
p_ctx = boost::static_pointer_cast<void>(context_);
context_->set_options(boost::asio::ssl::context::default_workarounds);
context_->use_certificate_chain_file(cert_chain_file);
context_->use_certificate_file(cert_file, boost::asio::ssl::context::pem);
context_->use_private_key_file(cert_file, boost::asio::ssl::context::pem);
context_->set_verify_mode(boost::asio::ssl::verify_peer | boost::asio::ssl::verify_fail_if_no_peer_cert);
context_->set_verify_callback(boost::bind(&verify_certificate_cb, _1, _2));
if (param_values[ID_CIPHER_LIST].int32_value != 0)
{
std::string cipher_list = "";
generate_cipher_list(param_values[ID_CIPHER_LIST].int32_value, cipher_list);
MA5G_logger::log(PRIORITY_INFO, "Supported cipher list %s", cipher_list.c_str());
SSL_CTX_set_cipher_list((reinterpret_cast<boost::asio::ssl::context*>(p_ctx.get()))->native_handle(),
cipher_list.c_str());
}
in the cipher_list, I am supporting below list
AES128-SHA:AES256-SHA:AES128-SHA256:AES256-SHA256:AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA
With ECDSA certificates if I use cipher_list given above then client can not connect to the server and gives error "No shared cipher". But if I do not give cipher_list then the client can successfully connect to the server. The same cipher list works fine with RSA certificates.
The same ECDSA certificates work fine if I use openssl s_server with -cipher option to provide supported cipher_list
Can anyone help with this issue?
No sorry buddy I found the answer after lot of research.
The problem is with the cipher list and not with the code / certificate.
The same certificate uses ECDHE-ECDSA-AES256-SHA cipher with openssl client-server while used ECDH-ECDSA-AES256-SHA cipher for boost asio SSL client-server.
Anyways thanks #rkyser for your help!
I found this buried in the FAQ of the openssl-1.0.1 source code:
Why can't I make an SSL connection to a server using a DSA certificate?
Typically you'll see a message saying there are no shared ciphers when
the same setup works fine with an RSA certificate. There are two
possible causes. The client may not support connections to DSA servers
most web browsers (including Netscape and MSIE) only support
connections to servers supporting RSA cipher suites. The other cause
is that a set of DH parameters has not been supplied to the server. DH
parameters can be created with the dhparam(1) command and loaded using
the SSL_CTX_set_tmp_dh() for example: check the source to s_server in
apps/s_server.c for an example.
So based on this, make sure you are setting your DH parameters using SSL_CTX_set_tmp_dh().