Check & print remote certificate
openssl s_client -connect <hostname>:<port> -showcerts
The web is moving to HTTPS, preventing network attackers from observing or injecting page contents. But HTTPS needs TLS certificates, and while deployment is increasingly a solved issue thanks to the ACME protocol and Let's Encrypt, development still mostly ends up happening over HTTP because no one can get an universally valid certificate for localhost.
SSLyze is a Python tool that can analyze the SSL configuration of a server by connecting to it. It is designed to be fast and comprehensive, and should help organizations and testers identify misconfigurations affecting their SSL servers.
Key features include:
- Multi-processed and multi-threaded scanning (it's fast)
- SSL 2.0/3.0 and TLS 1.0/1.1/1.2 compatibility
- Performance testing: session resumption and TLS tickets support
- Security testing: weak cipher suites, insecure renegotiation, CRIME, Heartbleed and more
- Server certificate validation and revocation checking through OCSP stapling
- Support for StartTLS handshakes on SMTP, XMPP, LDAP, POP, IMAP, RDP and FTP
- Support for client certificates when scanning servers that perform mutual authentication
- XML output to further process the scan results
- And much more !
apt-get install -t strech-backports python3-nacl
PyNaCl is a Python binding to libsodium, which is a fork of the Networking and Cryptography library. These libraries have a stated goal of improving usability, security and speed. It supports Python 2.7 and 3.4+ as well as PyPy 2.6+.
Features
Digital signatures
Secret-key encryption
Public-key encryption
Hashing and message authentication
Password based key derivation and password hashings I plan to move from a proprietary calendaring to a more „ressource-aware” open source solution, I decided to give Radicale a try. It is open source, appears to be rather pragmatic in its approach to „standards” and has a small footprint in regards to system requirements.
With me running Debian 8 on my server, I decided to stick with the available package and not install „from source”. So a quick „apt-get install radicale” took care of installing the necessary software (do not forget to enable the Radicale daemon in /etc/default/radicale).
The configuration of Radicale is rather straightforward and simple. In regards to transport security, You can reuse an existing TLS certificate (or get a new one from Let’s encrypt). For authentication, you can choose between several options. As I don’t have an LDAP server (yet) and I didn’t want to create a .httpasswd entry for each user, I chose „IMAP”. So Radicale will validate all credentials against the local IMAP server (Dovecot in my case).
The Pound program is a reverse proxy, load balancer and HTTPS front-end for Web server(s). Pound was developed to enable distributing the load among several Web-servers and to allow for a convenient SSL wrapper for those Web servers that do not offer it natively. Pound is distributed under the GPL - no warranty, it's free to use, copy and give away.
WHAT POUND IS:
a reverse-proxy: it passes requests from client browsers to one or more back-end servers.
a load balancer: it will distribute the requests from the client browsers among several back-end servers, while keeping session information.
an SSL wrapper: Pound will decrypt HTTPS requests from client browsers and pass them as plain HTTP to the back-end servers.
an HTTP/HTTPS sanitizer: Pound will verify requests for correctness and accept only well-formed ones.
a fail over-server: should a back-end server fail, Pound will take note of the fact and stop passing requests to it until it recovers.
a request redirector: requests may be distributed among servers according to the requested URL.Pound is a very small program, easily audited for security problems. It can run as setuid/setgid and/or in a chroot jail. Pound does not access the hard-disk at all (except for reading the certificate file on start, if required) and should thus pose no security threat to any machine.
During the TLS interim meeting of last week (Oct 22 2014) I suggested that TLS
1.3 should abandon signature-based authentication (other than for certificates)
and be based solely on a combination of ephemeral Diffie-Hellman for PFS and
static Diffie-Hellman for authentication. This has multiple benefits including
major performance gain (by replacing the per-handshake RSA signature by the
server with a much cheaper elliptic curve exponentiation), compatibility with
the mechanisms required for forward secrecy, natural accommodation of a 0-RTT
option, and a simple extension without signatures for client authentication.
Below I present a schematic representation of the proposed protocol referred
to as OPTLS where OPT stands for OPTimized and/or for One-Point-Three.
The presentation is sketchy and omits the exact procedure for key derivation.
The latter is a crucial component for the security of the protocol, but
before getting into these details we want to get a sense of whether the WG is
interested in this approach. In the meantime, Hoeteck Wee and myself are
working on the details of the protocol and the security proof.
We describe a setting with optional 0-RTT and server-only authentication.
Client authentication can be added as a further option or as an extension
(similar to the current 1.3 proposal) - see below.
duraconf - A collection of hardened configuration files for SSL/TLS services
http://www.appelbaum.net/
stunnel - universal SSL tunnel
The stunnel program is designed to work as an SSL encryption wrapper between remote client and local (inetd-startable) or remote server. It can be used to add SSL functionality to commonly used inetd daemons like POP2, POP3, and IMAP servers without any changes in the programs' code. Stunnel uses the OpenSSL library for cryptography, so it supports whatever cryptographic algorithms are compiled into the library.