c737cde947
Anywhere a module is mentioned, use its "non-u" name for consistency. The "import module" vs "import umodule" is something of a FAQ, and this commit intends to help clear that up. As a first approximation MicroPython is Python, and so imports should work the same as Python and use the same name, to a first approximation. The u-version of a module is a detail that can be learned later on, when the user wants to understand more and have finer control over importing. Existing Python code should just work, as much as it is possible to do that within the constraints of embedded systems, and the MicroPython documentation should match the idiomatic way to write Python code. With universal weak links for modules (via MICROPY_MODULE_WEAK_LINKS) users can consistently use "import foo" across all ports (with the exception of the minimal ports). And the ability to override/extend via "foo.py" continues to work well. Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
62 lines
2.4 KiB
ReStructuredText
62 lines
2.4 KiB
ReStructuredText
:mod:`ssl` -- SSL/TLS module
|
|
============================
|
|
|
|
.. module:: ssl
|
|
:synopsis: TLS/SSL wrapper for socket objects
|
|
|
|
|see_cpython_module| :mod:`python:ssl`.
|
|
|
|
This module provides access to Transport Layer Security (previously and
|
|
widely known as “Secure Sockets Layer”) encryption and peer authentication
|
|
facilities for network sockets, both client-side and server-side.
|
|
|
|
Functions
|
|
---------
|
|
|
|
.. function:: ssl.wrap_socket(sock, server_side=False, keyfile=None, certfile=None, cert_reqs=CERT_NONE, ca_certs=None, do_handshake=True)
|
|
|
|
Takes a `stream` *sock* (usually socket.socket instance of ``SOCK_STREAM`` type),
|
|
and returns an instance of ssl.SSLSocket, which wraps the underlying stream in
|
|
an SSL context. Returned object has the usual `stream` interface methods like
|
|
``read()``, ``write()``, etc.
|
|
A server-side SSL socket should be created from a normal socket returned from
|
|
:meth:`~socket.socket.accept()` on a non-SSL listening server socket.
|
|
|
|
- *do_handshake* determines whether the handshake is done as part of the ``wrap_socket``
|
|
or whether it is deferred to be done as part of the initial reads or writes
|
|
(there is no ``do_handshake`` method as in CPython).
|
|
For blocking sockets doing the handshake immediately is standard. For non-blocking
|
|
sockets (i.e. when the *sock* passed into ``wrap_socket`` is in non-blocking mode)
|
|
the handshake should generally be deferred because otherwise ``wrap_socket`` blocks
|
|
until it completes. Note that in AXTLS the handshake can be deferred until the first
|
|
read or write but it then blocks until completion.
|
|
|
|
Depending on the underlying module implementation in a particular
|
|
:term:`MicroPython port`, some or all keyword arguments above may be not supported.
|
|
|
|
.. warning::
|
|
|
|
Some implementations of ``ssl`` module do NOT validate server certificates,
|
|
which makes an SSL connection established prone to man-in-the-middle attacks.
|
|
|
|
CPython's ``wrap_socket`` returns an ``SSLSocket`` object which has methods typical
|
|
for sockets, such as ``send``, ``recv``, etc. MicroPython's ``wrap_socket``
|
|
returns an object more similar to CPython's ``SSLObject`` which does not have
|
|
these socket methods.
|
|
|
|
Exceptions
|
|
----------
|
|
|
|
.. data:: ssl.SSLError
|
|
|
|
This exception does NOT exist. Instead its base class, OSError, is used.
|
|
|
|
Constants
|
|
---------
|
|
|
|
.. data:: ssl.CERT_NONE
|
|
ssl.CERT_OPTIONAL
|
|
ssl.CERT_REQUIRED
|
|
|
|
Supported values for *cert_reqs* parameter.
|