|
| 1 | +***************************** |
| 2 | +mbedtls Network Stream Driver |
| 3 | +***************************** |
| 4 | + |
| 5 | +=========================== =========================================================================== |
| 6 | +**Driver Name:** **mbedtls** |
| 7 | +** Author:** Stéphane Adenot < [email protected]> |
| 8 | +**Available since:** |
| 9 | +=========================== =========================================================================== |
| 10 | + |
| 11 | + |
| 12 | +Purpose |
| 13 | +======= |
| 14 | + |
| 15 | +This network stream driver implements a TLS protected transport |
| 16 | +via the `MbedTLS library <https://www.trustedfirmware.org/projects/mbed-tls/>`_. |
| 17 | + |
| 18 | + |
| 19 | +Supported Driver Modes |
| 20 | +====================== |
| 21 | + |
| 22 | +- **0** - unencrypted transmission (just like `ptcp <ns_ptcp.html>`_ driver) |
| 23 | +- **1** - TLS-protected operation |
| 24 | + |
| 25 | +.. note:: |
| 26 | + |
| 27 | + Mode 0 does not provide any benefit over the ptcp driver. This |
| 28 | + mode exists for technical reasons, but should not be used. It may be |
| 29 | + removed in the future. |
| 30 | + |
| 31 | + |
| 32 | +Supported Authentication Modes |
| 33 | +============================== |
| 34 | + |
| 35 | +- **anon** - anonymous authentication as described in IETF's |
| 36 | + draft-ietf-syslog-transport-tls-12 Internet draft |
| 37 | + |
| 38 | +- **x509/fingerprint** - certificate fingerprint authentication as |
| 39 | + described in IETF's draft-ietf-syslog-transport-tls-12 Internet draft. |
| 40 | + The fingerprint must be provided as the SHA1 or the SHA256 hex string of |
| 41 | + the certificate. Multiple values must be separated by comma (,). |
| 42 | + A valid configuration would be e.G. |
| 43 | + :: |
| 44 | + |
| 45 | + StreamDriverPermittedPeers="SHA256:10:C4:26:1D:CB:3C:AB:12:DB:1A:F0:47:37:AE:6D:D2:DE:66:B5:71:B7:2E:5B:BB:AE:0C:7E:7F:5F:0D:E9:64,SHA1:DD:23:E3:E7:70:F5:B4:13:44:16:78:A5:5A:8C:39:48:53:A6:DD:25" |
| 46 | + |
| 47 | +- **x509/certvalid** - certificate validation only. x509/certvalid is |
| 48 | + a nonstandard mode. It validates the remote peers certificate, but |
| 49 | + does not check the subject name. This is weak authentication that may |
| 50 | + be useful in scenarios where multiple devices are deployed and it is |
| 51 | + sufficient proof of authenticity when their certificates are signed by |
| 52 | + the CA the server trusts. This is better than anon authentication, but |
| 53 | + still not recommended. **Known Problems** |
| 54 | + |
| 55 | +- **x509/name** - certificate validation and subject name authentication as |
| 56 | + described in IETF's draft-ietf-syslog-transport-tls-12 Internet draft |
| 57 | + |
| 58 | +.. note:: |
| 59 | + |
| 60 | + "anon" does not permit to authenticate the remote peer. As such, |
| 61 | + this mode is vulnerable to man in the middle attacks as well as |
| 62 | + unauthorized access. It is recommended NOT to use this mode. |
| 63 | + A certificate / key does not need to be configured in this authmode. |
| 64 | + |
| 65 | + |
| 66 | +CheckExtendedKeyPurpose |
| 67 | +======================= |
| 68 | + |
| 69 | +- **off** - by default this binary argument is turned off, which means |
| 70 | + that Extended Key Usage extension of certificates is ignored |
| 71 | + in cert validation. |
| 72 | + |
| 73 | +- **on** - if you turn this option on, it will check that peer's certificate |
| 74 | + contains the value for "TLS WWW Client" or "TLS WWW Server" |
| 75 | + respectively, depending whether we are on sending or receiving end of a |
| 76 | + connection. |
| 77 | + |
| 78 | +PrioritizeSAN |
| 79 | +============= |
| 80 | + |
| 81 | +- **off** - by default this binary argument is turned off, which means |
| 82 | + that validation of names in certificates goes per older RFC 5280 and either |
| 83 | + Subject Alternative Name or Common Name match is good and connection is |
| 84 | + allowed. |
| 85 | + |
| 86 | +- **on** - if you turn this option on, it will perform stricter name checking |
| 87 | + as per newer RFC 6125, where, if any SAN is found, contents of CN are |
| 88 | + completely ignored and name validity is decided based on SAN only. |
0 commit comments