On Sat, Feb 27, 2016 at 12:07:03PM +0100, Jiri Pirko wrote:
Fri, Feb 26, 2016 at 04:00:00PM CET, olichtne(a)redhat.com wrote:
>From: Ondrej Lichtner <olichtne(a)redhat.com>
>
>Added 3 new classes: SecureSocket, CtlSecSocket and SlaveSecSocket. The
>SecureSocket class encapsulates a normal socket object and adds what is
>basically a TLS Record Layer - adds a signature, padding and encrypts
>the entire message.
>
>The CtlSecSocket and SlaveSecSocket classes are child classes inheriting
>from the SecureSocket class and implement the handshake protocols used
>from the Controller or from the Slave side. The important method is
>handshake() that takes a sec_params parameter which is a dictionary
>describing how to do the handshake.
>
>Signed-off-by: Ondrej Lichtner <olichtne(a)redhat.com>
>---
> lnst/Common/SecureSocket.py | 377 ++++++++++++++++++++++++++++++++++++++++
> lnst/Controller/CtlSecSocket.py | 318 +++++++++++++++++++++++++++++++++
> lnst/Slave/SlaveSecSocket.py | 323 ++++++++++++++++++++++++++++++++++
> 3 files changed, 1018 insertions(+)
> create mode 100644 lnst/Common/SecureSocket.py
> create mode 100644 lnst/Controller/CtlSecSocket.py
> create mode 100644 lnst/Slave/SlaveSecSocket.py
>
>diff --git a/lnst/Common/SecureSocket.py b/lnst/Common/SecureSocket.py
>new file mode 100644
>index 0000000..d319c54
>--- /dev/null
>+++ b/lnst/Common/SecureSocket.py
>@@ -0,0 +1,377 @@
>+"""
>+This module defines a SecureSocket class that wraps the normal socket by adding
>+TLS-like functionality of providing data integrity, confidentiality and
>+authenticity. The reason why we're not using TLS is because the Python
>+implementation enforces the use of certificates and we want to also allow
>+password based authentication. This implements the common class, and the Slave
>+and Controller implement their sides of the handshake algorithms.
>+
>+Copyright 2016 Red Hat, Inc.
>+Licensed under the GNU General Public License, version 2 as
>+published by the Free Software Foundation; see COPYING for details.
>+"""
>+
>+__author__ = """
>+olichtne(a)redhat.com (Ondrej Lichtner)
>+"""
>+
>+import os
>+import cPickle
>+import hashlib
>+import hmac
>+import cryptography.exceptions
>+from cryptography.hazmat.primitives import hashes
>+from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
>+from cryptography.hazmat.primitives.asymmetric import padding, ec
>+from cryptography.hazmat.primitives.asymmetric.ec import EllipticCurvePrivateKey
>+from cryptography.hazmat.primitives.asymmetric.ec import EllipticCurvePublicKey
>+from cryptography.hazmat.primitives.asymmetric.rsa import RSAPrivateKey
>+from cryptography.hazmat.primitives.asymmetric.rsa import RSAPublicKey
>+from cryptography.hazmat.primitives.asymmetric.dsa import DSAPrivateKey
>+from cryptography.hazmat.primitives.asymmetric.dsa import DSAPublicKey
>+from cryptography.hazmat.backends import default_backend
>+
>+DH_GROUP = {"p":
int("0xFFFFFFFFFFFFFFFFC90FDAA22168C234C4C6628B80DC1CD1"\
>+ "29024E088A67CC74020BBEA63B139B22514A08798E3404DD"\
>+ "EF9519B3CD3A431B302B0A6DF25F14374FE1356D6D51C245"\
>+ "E485B576625E7EC6F44C42E9A637ED6B0BFF5CB6F406B7ED"\
>+ "EE386BFB5A899FA5AE9F24117C4B1FE649286651ECE45B3D"\
>+ "C2007CB8A163BF0598DA48361C55D39A69163FA8FD24CF5F"\
>+ "83655D23DCA3AD961C62F356208552BB9ED529077096966D"\
>+ "670C354E4ABC9804F1746C08CA18217C32905E462E36CE3B"\
>+ "E39E772C180E86039B2783A2EC07A28FB5C55DF06F4C52C9"\
>+ "DE2BCBF6955817183995497CEA956AE515D2261898FA0510"\
>+ "15728E5A8AACAA68FFFFFFFFFFFFFFFF", 16),
Wouldn't it make sense to make this configurable and not hard-coded?
Not really... these are VERY long primes - 2048 bit long _safe_ primes,
plus the SRP parameters have one more restriction. I originally wanted
to generate these on the fly, but that operation can take minutes... If
I wanted to have these configurable I'd have to do a similar operation
to check if their usable.
Besides, this is as far as I understand it completely ok to do and there
are even RFCs with these precomputed (recommended) parameters which are
public. The parameters I'm using are ones that I've generated through
openssl so these should be a bit better than the RFC ones since their
unique to us.
One other thing is that these parameters need to be IDENTICAL on both
the client and the server side of the connection so if these were
configurable I'd have to add another step to the handshake methods.
-Ondrej