In the book Erlang Programming one of the exercises proposed was to print on screen the request coming from a browser using gen_tcp. I made it for http requests as follows:
-module(tcp).
-export([server/0, wait_connect/2]).
server() ->
{ok, ListenSocket} = gen_tcp:listen(1234, [binary, {active, false}]),
wait_connect(ListenSocket,0).
wait_connect(ListenSocket, Count) ->
{ok, Socket} = gen_tcp:accept(ListenSocket),
spawn(?MODULE, wait_connect, [ListenSocket, Count+1]),
get_request(Socket, [], Count).
get_request(Socket, BinaryList, Count) ->
Request = gen_tcp:recv(Socket, 0),
io:format("~p~n", [Request]).
Now I am wondering how this can be done in case of https request. Can you provide a very simple example, or point me to some resource on books or online?
Here is the user guide for Erlang SSL application:
Erlang -- SSL User Guide
The guide contains also, in the API chapter, a paragraph on updating existing connections to SSL.
Regarding your code, you should do something like:
on server and client side you have to issue:
ssl:start()
server side: handshake SSL (remember to set 'active' to false for the listening socket)
{ok, SSLSocket} = ssl:ssl_accept(Socket, [{cacertfile, "cacerts.pem"},
{certfile, "cert.pem"}, {keyfile, "key.pem"}]).
where "cacerts.pem", "cert.pem", "key.pem" are files related to SSL certification
client side: upgrade connection to SSL:
{ok, SSLSocket} = ssl:connect(Socket, [{cacertfile, "cacerts.pem"},
{certfile, "cert.pem"}, {keyfile, "key.pem"}], infinity).
As per documentation, now SSLSocket is a ssl channel that can be used to send messages like:
ssl:send(SSLSocket, "foo").
Hope this helps!
I would suggest to read the following article about SSL sockets in Erang that contains complete code of the SSL echo server and client.
Erlang SSL sockets example - ssl server & client)
Related
I'm trying to create a simple SSL server that uses a Pre-Shared Key to authenticate a client (no ssl certs). It seems this functionality exists in the Erlang ssl module, but it's unclear to me how to use it effectively. It's worth mentioning I'm attempting to use it in Elixir (eventually as a GenServer).
I've made a simple example that should just accept a connection, and then proceed with a handshake when a client connects.
# Server
defmodule SimpleSSLServer do
def start() do
:ssl.start()
# Limit Cipers to what supports PSKs
ciphers_suites =
:ssl.cipher_suites(:all, :"tlsv1.3")
|> Enum.filter(&match?(%{cipher: cip} when cip in [:aes_128_gcm], &1))
{:ok, listen_socket} =
:ssl.listen(8085,
reuseaddr: true,
user_lookup_fun:
{&user_lookup/3, "001122334455ff001122334455ff001122334455ff001122334455ff"},
ciphers: ciphers_suites
)
{:ok, transport_socket} = :ssl.transport_accept(listen_socket)
{:ok, _socket} = :ssl.handshake(transport_socket)
end
def user_lookup(:psk, _id, state) do
{:ok, state}
end
end
SimpleSSLServer.start()
# Client
openssl s_client -connect 127.0.0.1:8085 -psk 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f -tls1_3 -ciphersuites TLS_AES_128_GCM_SHA256
This application compiles, and when you run the server and connect a client the following message occurs:
** (exit) exited in: :gen_statem.call(#PID<0.187.0>, {:start, :infinity}, :infinity)
** (EXIT) an exception was raised:
** (MatchError) no match of right hand side value: {:state, {:static_env, :server, :gen_tcp, :tls_gen_connection, :tcp, :tcp_closed, :tcp_error, :tcp_passive, 'localhost', 8085, ...super long amount of state
(ssl 10.6.1) tls_handshake_1_3.erl:652: :tls_handshake_1_3.do_start/2
(ssl 10.6.1) tls_connection_1_3.erl:269: :tls_connection_1_3.start/3
(stdlib 3.17) gen_statem.erl:1203: :gen_statem.loop_state_callback/11
(ssl 10.6.1) tls_connection.erl:154: :tls_connection.init/1
(stdlib 3.17) proc_lib.erl:226: :proc_lib.init_p_do_apply/3
(stdlib 3.17) gen.erl:220: :gen.do_call/4
(stdlib 3.17) gen_statem.erl:693: :gen_statem.call_dirty/4
(ssl 10.6.1) ssl_gen_statem.erl:1187: :ssl_gen_statem.call/2
(ssl 10.6.1) ssl_gen_statem.erl:223: :ssl_gen_statem.handshake/2
test.exs:18: SimpleSSLServer.start/0
Any help is appreciated, this is likely something very obvious I'm missing!
I am finding it impossible to set up an encrypted connection with a RabbitMQ broker using python's pika library on the client side. My starting point was the pika tutorial example here but I cannot make it work. I have proceeded as follows.
(1) The RabbitMQ configuration file was:
listeners.tcp.default = 5672
listeners.ssl.default = 5671
ssl_options.verify = verify_peer
ssl_options.fail_if_no_peer_cert = false
ssl_options.cacertfile = /etc/cert/tms.crt
ssl_options.certfile = /etc/cert/tms.crt
ssl_options.keyfile = /etc/cert/tmsPrivKey.pem
auth_mechanisms.1 = PLAIN
auth_mechanisms.2 = AMQPLAIN
auth_mechanisms.3 = EXTERNAL
(2) The rabbitmq-auth-mechanism-ssl plugin was enabled with the following command:
rabbitmq-plugins enable rabbitmq_auth_mechanism_ssl
Successful enabling was confirmed by checking the enable status through: rabbitmq-plugins list.
(3) The correctness of the TLS certificates was verified by using openssl tools as described here.
(4) The client-side program to set up the connection was:
#!/usr/bin/env python
import logging
import pika
import ssl
from pika.credentials import ExternalCredentials
logging.basicConfig(level=logging.INFO)
context = ssl.create_default_context(
cafile="/Xyz/sampleNodeCert/tms.crt")
context.load_cert_chain("/Xyz/sampleNodeCert/node.crt",
"/Xyz/sampleNodeCert/nodePrivKey.pem")
ssl_options = pika.SSLOptions(context, '127.0.0.1')
conn_params = pika.ConnectionParameters(host='127.0.0.1',
port=5671,
ssl_options=ssl_options,
credentials=ExternalCredentials())
with pika.BlockingConnection(conn_params) as conn:
ch = conn.channel()
ch.queue_declare("foobar")
ch.basic_publish("", "foobar", "Hello, world!")
print(ch.basic_get("foobar"))
(5) The client-side program failed with the following error message:
pika.exceptions.ProbableAuthenticationError: ConnectionClosedByBroker: (403) 'ACCESS_REFUSED - Login was refused using authentication mechanism EXTERNAL. For details see the broker logfile.'
(6) The log message in the RabbitMQ broker was:
2019-10-15 20:17:46.028 [info] <0.642.0> accepting AMQP connection <0.642.0> (127.0.0.1:48252 -> 127.0.0.1:5671)
2019-10-15 20:17:46.032 [error] <0.642.0> Error on AMQP connection <0.642.0> (127.0.0.1:48252 -> 127.0.0.1:5671, state: starting):
EXTERNAL login refused: user 'CN=www.node.com,O=Node GmbH,L=NodeTown,ST=NodeProvince,C=DE' - invalid credentials
2019-10-15 20:17:46.043 [info] <0.642.0> closing AMQP connection <0.642.0> (127.0.0.1:48252 -> 127.0.0.1:5671)
(7) The environment in which this test was done is Ubuntu 18.04 using RabbitMQ 3.7.17 on Erlang 22.0.7. On the client side, python3 version 3.6.8 was used.
Questions: Does anyone have any idea as to why my test fails? Where can I find a complete working example of setting up an encrypted connection to RabbitMQ using pika?
NB: I am familiar with this post but none of the tips in the post helped me.
After studying the link provided above by Luke Bakken, I am now in a position to answer my own question. The main change with respect to my original example is that I configure the RabbitMQ broker with a passwordless user which has the same name as the CN field of the TLS certificate on both the server and the client side. To illustrate, below, I go through my example again in detail:
(1) The RabbitMQ configuration file is:
listeners.tcp.default = 5672
listeners.ssl.default = 5671
ssl_cert_login_from = common_name
ssl_options.verify = verify_peer
ssl_options.fail_if_no_peer_cert = true
ssl_options.cacertfile = /etc/cert/tms.crt
ssl_options.certfile = /etc/cert/tms.crt
ssl_options.keyfile = /etc/cert/tmsPrivKey.pem
auth_mechanisms.1 = EXTERNAL
auth_mechanisms.2 = PLAIN
auth_mechanisms.3 = AMQPLAIN
Note that, with the ssl_cert_login_from configuration option, I am asking for the username of the RabbitMQ account to be taken from the "common name" (CN) field of the TLS certificate.
(2) The rabbitmq-auth-mechanism-ssl plugin is enabled with the following command:
rabbitmq-plugins enable rabbitmq_auth_mechanism_ssl
Successful enabling can be confirmed by checking the enable status through command: rabbitmq-plugins list.
(3) The signed TLS certificate must have the issuer and subject CN fields equal to each other and equal to the hostname of the RabbitMQ broker node. In my case, inspection of the RabbitMQ log file (in /var/log/rabbitmq) shows that the broker is running on a node called: rabbit#pnp-vm2. The host name is therefore pnp-vm2. In order to check the CN fields of the client-side certificate, I use the following command:
ap#pnp-vm2:openssl x509 -noout -text -in /etc/cert/node.crt | fgrep CN
Issuer: C = CH, ST = CH, L = Location, O = Organization GmbH, CN = pnp-vm2
Subject: C = DE, ST = NodeProvince, L = NodeTown, O = Node GmbH, CN = pnp-vm2
As you can see, both the Issuer CN field and the Subject CN Field are equal to: "pnp-vm2" (which is the hostname of the RabbitMQ broker, see above). I tried using this name for only one of the two CN fields but then the connection to the broker could not be established. In my test environment, it was easy to create a client certificate with identical CN names but, in an operational environment, this may be a lot harder to do. Also, I do not quite understand the reason for this constraint: is it a bug or it is a feature? And does it originate in the particular RabbitMQ library I am using (python's pika) or in the AMQP protocol? These question probably deserve a dedicated post.
(4) The client-side program to set up the connection is:
#!/usr/bin/env python
import logging
import pika
import ssl
from pika.credentials import ExternalCredentials
logging.basicConfig(level=logging.INFO)
context = ssl.create_default_context(cafile="/home/ap/RocheTe/cert/sampleNodeCert/tms.crt")
context.load_cert_chain("/home/ap/RocheTe/cert/sampleNodeCert/node.crt",
"/home/ap/RocheTe/cert/sampleNodeCert/nodePrivKey.pem")
ssl_options = pika.SSLOptions(context, 'pnp-vm2')
conn_params = pika.ConnectionParameters(host='a.b.c.d',
port=5671,
ssl_options=ssl_options,
credentials=ExternalCredentials(),
heartbeat=0)
with pika.BlockingConnection(conn_params) as conn:
ch = conn.channel()
ch.queue_declare("foobar")
ch.basic_publish("", "foobar", "Hello, world!")
print(ch.basic_get("foobar"))
input("Press Enter to continue...")
Here, "a.b.c.d" is the IP address of the machine on which the RabbitMQ broker is running.
(5) The environment in which this test was done is Ubuntu 18.04 using RabbitMQ 3.7.17 on Erlang 22.0.7. On the client side, python3 version 3.6.8 was used.
One final word of warning: with this configuration, I was able to establish a secure connection to the RabbitMQ Broker but, for reasons which I still do not understand, it became impossible to start the RabbitMQ Web Management Tool...
I write this simple code with ssltcp:
ssl:start().
{ok, ListenSocket} = ssl:listen(9999, [{certfile, "cert.pem"}, {keyfile, "key.pem"},{reuseaddr, true}]).
{ok, Socket} = ssl:transport_accept(ListenSocket).
ssl:ssl_accept(Socket).
ssl:setopts(Socket, [{active, once}]).
it works fine but when i replace {active, once} with {active, 3}, returns this error:
{error,{options,{socket_options,{active,3}}}}
How can use {active, N} mode in secure tcp?
The {active,N} mode is not implemented for SSL connections. I originally wrote the {active,N} mode and when I looked into possibly implementing it for SSL, I found that the way Erlang SSL sockets are implemented over the top of underlying TCP sockets involves changes on those sockets between active and passive modes as part of the protocol implementation, and so implementing {active,N} for SSL is not simply a matter of opening an underlying socket in that mode.
I am developing an application using nitrogen web framework over cowboy web server. When i run the server over http is works perfectly well. Now in production the application must run on https.
I have modified the cowboy.config file in the etc directory of nitrogen from default
% vim: ts=4 sw=4 et ft=erlang
[
{cowboy,[
{bind_address,"127.0.0.1"},
{port,80},
{server_name,nitrogen},
{document_root,"./site/static"},
%% some comments.........
{static_paths, ["/js/","/images/","/css/","/nitrogen/","/favicon.ico"]}
]}
].
to this one
% vim: ts=4 sw=4 et ft=erlang
[
{cowboy,[
{bind_address,"127.0.0.1"},
{port,443},
{server_name,nitrogen},
{cacertfile, "Path/cacert.pem"},
{certfile, "Path/webservercert.pem"},
{keyfile, "Path/webserverkey.pem"},
{password, "webserverkeypassphrase"}
{document_root,"./site/static"},
%% some comments.........
{static_paths, ["/js/","/images/","/css/","/nitrogen/","/favicon.ico"]}
]}
].
Where Path is the absolute path to the SSL certificate that I generated and signed it by myself using openSSL. I take my site name as domainname.com but i first create a CA following openSSl documentation
I also modified the Supervisor callbacks in the nitrogen_sup.erl file found in nitrogen/site/scr from the default
%% ===================================================================
%% Supervisor callbacks
%% ===================================================================
init([]) ->
%% Start the Process Registry...
application:start(crypto),
application:start(nprocreg),
application:start(ranch),
%% Start Cowboy...
application:start(cowboy),
{ok, BindAddress} = application:get_env(cowboy, bind_address),
{ok, Port} = application:get_env(cowboy, port),
{ok, ServerName} = application:get_env(cowboy, server_name),
{ok, DocRoot} = application:get_env(cowboy, document_root),
{ok, StaticPaths} = application:get_env(cowboy, static_paths),
io:format("Starting Cowboy Server (~s) on ~s:~p, root: '~s'~n",
[ServerName, BindAddress, Port, DocRoot]),
Dispatch = init_dispatch(DocRoot, StaticPaths),
{ok, _} = cowboy:start_http(http, 100,
[
{port, Port}
], [
{env, [{dispatch, Dispatch}]},
{max_keepalive, 50}
]),
{ok, { {one_for_one, 5, 10}, []} }.
to this one below
%% ===================================================================
%% Supervisor callbacks
%% ===================================================================
init([]) ->
%% Start the Process Registry...
application:start(crypto),
application:start(nprocreg),
application:start(ranch),
%% Start Cowboy...
application:start(cowboy),
{ok, BindAddress} = application:get_env(cowboy, bind_address),
{ok, Port} = application:get_env(cowboy, port),
{ok, ServerName} = application:get_env(cowboy, server_name),
{ok, DocRoot} = application:get_env(cowboy, document_root),
{ok, StaticPaths} = application:get_env(cowboy, static_paths),
{ok, CAcertfile} = application:get_env(cowboy, cacertfile),
{ok, Certfile} = application:get_env(cowboy, certfile),
{ok, Keyfile} = application:get_env(cowboy, keyfile),
{ok, Password} = application:get_env(cowboy, password),
io:format("Starting Cowboy Server (~s) on ~s:~p, root: '~s'~n",
[ServerName, BindAddress, Port, DocRoot]),
Dispatch = init_dispatch(DocRoot, StaticPaths),
{ok, _} = cowboy:start_https(https, 100,
[
{port, Port},
{cacertfile, CAcertfile},
{certfile, Certfile},
{keyfile, Keyfile},
{password, Password}
], [
{env, [{dispatch, Dispatch}]},
{max_keepalive, 50}
]),
{ok, { {one_for_one, 5, 10}, []} }.
Using sync:go() the file compiles and reloads. However i closed nitrogen and started it again.
in the shell I use the curl utility to test if the server is listening
$ curl --cacert Absolute_path/cacert.pem -i https://domainname.com
the response is posite as the contents on the index page are displayed in the shell
However, when i go to Firefox browser it throws a security warning which i admitted an except that i known its cause i permanently add to the exceptions. When I try getting the page again the browser throws this error.
Secure Connection Failed
The key does not support the requested operation.
(Error code: sec_error_invalid_key)
.The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
.Please contact the website owners to inform them of this problem. Alternatively, use the command found in the help menu to report this broken site.
When i checked in the nitrogen console if found this error report
(nitrogen#127.0.0.1)4> user#user:~/nitrogen/rel/nitrogen$
user#user:~/nitrogen/rel/nitrogen$ sudo ./bin/nitrogen console
Exec: /home/user/nitrogen/rel/nitrogen/erts-5.10.4/bin/erlexec -boot /home/user/nitrogen/rel/nitrogen/releases/2.2.2/nitrogen -mode interactive -config /home/user/nitrogen/rel/nitrogen/etc/app.config -config /home/user/nitrogen/rel/nitrogen/etc/cowboy.config -config /home/user/nitrogen/rel/nitrogen/etc/sync.config -args_file /home/dotshule/nitrogen/rel/nitrogen/etc/vm.args -- console
Root: /home/dotshule/nitrogen/rel/nitrogen
Erlang R16B03 (erts-5.10.4) [source] [smp:2:2] [async-threads:5] [hipe] [kernel-poll:true]
Eshell V5.10.4 (abort with ^G)
(nitrogen#127.0.0.1)1> Starting Cowboy Server (nitrogen) on 127.0.0.1:443, root: './site/static'
=ERROR REPORT==== 20-Feb-2014::14:51:12 ===
SSL: certify: tls_connection.erl:375:Fatal error: unknown ca
Now what i do not understand is whether the server is the one refusing my certificate or i have skipped a step, or one or two steps have gone wrong or the problem is on my self created CA (root certificate cacert.pem) or the problem is on openSSL!
I have now become suspicious that may be if i generate my CSR and send it to the trusted CA such as symantec, digcert, thawte, geotrust, ..etc. the resulting certificate may also fail to work.
I need your help please on this https of nitrogen over cowboy webserver issue. Thaks for all your help so far....
I'm not sure why cowboy would be throwing that particular error (tls_connection.erl is actually a part of Erlang, rather than Cowboy or Nitrogen).
That said, when it comes to running SSL with Nitrogen, I usually just recommend to users to use nginx as a reverse proxy in front of Nitrogen, and there are nginx configuration examples on the Nitrogen site at http://nitrogenproject.com/doc/config.html (scroll down to SSL-only example).
I realize that's not exactly ideal, so alternatively, I'd see if nginx or apache are able to successfully serve sample pages with the same key/cert combos. Obviously, the "unknown ca" error is saying that Erlang doesn't like the fact that it's a self-signed certificate. So you could experiment with using other signed certs/keys you may have lying around, or generate a real one for free at StartSSL.com and see if the error continues presenting itself.
Again, none of these are solid answers, but they should help point you in a number of directions to help solving your problems.
Personally, I run all my Nitrogen instances behind nginx and let nginx deal with the SSL and load-balancing.
My methodology actually works, I have successfully tested it using SYMANTEC and VERISIGN SSL certificates and it could be a formal way of installing SSL certificates on Cowboy web server.
From CherryPy 3.0 and onwards, one-way SSL can be turned on simply by pointing to the server certificate and private key, like this:
import cherrypy
class HelloWorld(object):
def index(self):
return "Hello SSL World!"
index.exposed = True
cherrypy.server.ssl_certificate = "keys/server.crt"
cherrypy.server.ssl_private_key = "keys/server.crtkey"
cherrypy.quickstart(HelloWorld())
This enables clients to validate the server's authenticity. Does anyone know whether CherryPy supports 2-way ssl, e.g. where the server can also check client authenticity by validating a client certificate?
If yes, could anyone give an example how is that done? Or post a reference to an example?
It doesn't out of the box. You'd have to patch the wsgiserver to provide that feature. There is a ticket (and patches) in progress at http://www.cherrypy.org/ticket/1001.
I have been looking for the same thing. I know there are some patches on the CherryPy site.
I also found the following at CherryPy SSL Client Authentication. I haven't compared this vs the CherryPy patches but maybe the info will be helpful.
We recently needed to develop a quick
but resilient REST application and
found that CherryPy suited our needs
better than other Python networking
frameworks, like Twisted.
Unfortunately, its simplicity lacked a
key feature we needed, Server/Client
SSL certificate validation. Therefore
we spent a few hours writing a few
quick modifications to the current
release, 3.1.2. The following code
snippets are the modifications we
made:
cherrypy/_cpserver.py
## -55,7 +55,6 ## instance = None ssl_certificate = None ssl_private_key
= None
+ ssl_ca_certificate = None nodelay = True
def __init__(self):
cherrypy/wsgiserver/__init__.py
## -1480,6 +1480,7 ##
# Paths to certificate and private key files ssl_certificate = None ssl_private_key = None
+ ssl_ca_certificate = None
def __init__(self, bind_addr, wsgi_app, numthreads=10, server_name=None, max=-1, request_queue_size=5, timeout=10, shutdown_timeout=5):
## -1619,7 +1620,9 ##
self.socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) if self.nodelay: self.socket.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)
- if self.ssl_certificate and self.ssl_private_key:
+ if self.ssl_certificate and self.ssl_private_key and \
+ self.ssl_ca_certificate:
+ if SSL is None: raise ImportError("You must install pyOpenSSL to use HTTPS.")
## -1627,6 +1630,11 ## ctx = SSL.Context(SSL.SSLv23_METHOD) ctx.use_privatekey_file(self.ssl_private_key) ctx.use_certificate_file(self.ssl_certificate)
+ x509 = crypto.load_certificate(crypto.FILETYPE_PEM,
+ open(self.ssl_ca_certificate).read())
+ store = ctx.get_cert_store()
+ store.add_cert(x509)
+ ctx.set_verify(SSL.VERIFY_PEER | SSL.VERIFY_FAIL_IF_NO_PEER_CERT, lambda *x:True) self.socket = SSLConnection(ctx, self.socket) self.populate_ssl_environ()
The above patches require the
inclusion of a new configuration
option inside of the CherryPy server
configuration,
server.ssl_ca_certificate. This
option identifies the certificate
authority file that connecting clients
will be validated against, if the
client does not present a valid client
certificate it will close the
connection immediately.
Our solution has advantages and
disadvantages, the primary advantage
being if the connecting client doesn’t
present a valid certificate it’s
connection is immediately closed.
This is good for security concerns as
it does not permit the client any
access into the CherryPy application
stack. However, since the restriction
is done at the socket level the
CherryPy application can never see the
client connecting and hence the
solution is somewhat inflexible.
An optimal solution would allow the
client to connect to the CherryPy
socket and send the client certificate
up into the application stack. Then a
custom CherryPy Tool would validate
the certificate inside of the
application stack and close the
connection if necessary; unfortunately
because of the structure of CherryPy’s
pyOpenSSL implementation it is
difficult to retrieve the client
certificate inside of the application
stack.
Of course the patches above should
only be used at your own risk. If you
come up with a better solution please
let us know.
If the current version of CherryPy does not support client certificate verification, it is possible to configure CherryPy to listen to 127.0.0.1:80, install HAProxy to listen to 443 and verify client side certificates and to forward traffic to 127.0.0.1:80
HAProxy is simple, light, fast and reliable.
An example of HAProxy configuration