On 06/04/17 06:08, Илья Шипицин wrote: > > > 2017-04-06 3:26 GMT+05:00 David Sommerseth > <open...@sf.lists.topphemmelig.net > <mailto:open...@sf.lists.topphemmelig.net>>: > > On 05/04/17 23:43, Илья Шипицин wrote: > > hello! > > > > just curious how renegotiation is handled in "https" ? > > is it "an abbrevated ssl handshake" (RFC 2246) or ... ? > > The HTTPS and OpenVPN protocol is not comparable in this regard at all. > AFAIR, OpenVPN does not make use of the TLS renegotiation possibility at > all. So a renegotiation in OpenVPN actually results in a completely new > and fresh TLS session, not related to previous TLS sessions at all. > > > both HTTPS and OpenVPN are > > 1) client-->server > 2) long running > 3) SSL based > > > they are similar from many point of view > > as, renegotiation does occur for https, and we do not observe "hourly" > CPU peaks, I think it worth not reinventing the wheel here
This is equal to say HTTPS and OpenVPN are both networked applications,
disregarding the differences of *how* these applications really work.
Just like apples and oranges are both fruits. They are still very much
different.
HTTPS in this context is quite misleading. We need to primarily talk
about SSL/TLS. HTTPS is basically HTTP over an SSL/TLS connection. So
keep that in mind. The same goes for any SSL/TLS enabled service
(IMAPS/POP3S, SMTP, XMPP, etc, etc)
A typical HTTPS connection consists of:
a) The client connects to the HTTPS server using a *TCP* port,
b) The TLS handshake happens (managed by the SSL library)
c) Client sends plain text data to the SSL library
d) SSL library encrypts the data
e) Encrypted data is sent to the server
f) Server decrypts data
g) the webserver receives the (decrypted) plain text data,
processes the request and sends the plain text result to
SSL library
h) SSL library encrypts the data
i) Encrypted result is sent back to the client
j) Client decrypts data, lets the application process the
plain text data
k) Client closes the connection to the server
For *each* HTTPS request, these steps happens. The TLS handshake is CPU
intensive and costs CPU cycles. So there exists TLS extensions for
session resumption, which allows the following connections to re-use the
already negotiated encryption keys. And to ensure this keying material
is rotated, the application *may* choose to make use of the TLS
renegotiation feature. But it is not a requirement.
OpenVPN is different in regards to it's SSL/TLS usage is not bound to
TCP (SSL/TLS is by design TCP _only_). OpenVPN splits the communication
over a single UDP/TCP socket into a control channel and a data channel.
The data channel uses _only_ symmetric encryption, while the TLS packets
is sent over the control channel. *All* OpenVPN packets, regardless of
data or control channel, are encapsulated with some more information
about the client, reliability details, as well as which channel the
packet belongs - and a few other bits. This also enables OpenVPN to
send SSL/TLS packets over a UDP socket.
A typical OpenVPN TLS connection goes more like this:
1) Client connects to the server, using * UDP _or_ TCP*
2) TLS handshake goes over the control channel
3) Once the TLS handshake has completed successfully, encryption
keys are derived for the data channel. This key is not strictly
tied to the TLS specification itself, but can be seen as an
independent key (this is extremely simplified and not 100% correct,
but this background is enough to explain the next steps).
The next things the control channel transports are the network
configuration, routing, user/password authentication, other
--push'ed options, OCC details, etc.
4) packets sent on the TUN/TAP device gets picked up as "plain text",
gets encrypted and sent to the remote side over the UDP/TCP socket
as data channel packets, decrypted and put on the remote sides'
TUN/TAP device. The encryption used here is the symmetric
encryption based on the keying material from step 3.
5) other OpenVPN features (--ping, etc) is sent at regular intervals
as control channel packets to the remote side and processed
accordingly there, responses are sent back. The data payload of
the control channel utilizes the SSL libraries TLS way of sending
encrypted data and decrypt it; similar to HTTPS.
6) goto 4, unless a --reneg-* situation hits, the client or server
decides to close the connection or other signals are received
7a) In case of --reneg-* situation, goto 2 and start a new TLS
handshake, and prepare a switch from old keys to new keys.
7b) In case of a request/signal to close the tunnel, close the UDP/TCP
socket and exit the program.
The *main* difference here is that while HTTPS initiates a new TCP
connection, implying the need for a TLS handshake for each connection,
OpenVPN have a single socket open for the life time of the VPN tunnel.
HTTPS utilizes very different approaches for session resumption and
renegotiations than OpenVPN, as HTTPS doesn't have the notion of control
or data packets. It's just a single socket for a single usage.
Web servers these days are also multi-threaded (or "multi-forked"), so
they can utilize multiple cores more efficiently. OpenVPN is *single
threaded*. So when one client starts a TLS renegotiation, it blocks all
the other connected clients until the renegotiation have completed.
When you then have 100 connected clients spending 1-2 seconds on each
renegotiation happening at the same time, you will have 100-200 seconds
of slow and lagging VPN tunnel. This does not mean that you will see a
CPU spike, as each client is handled serialized (one by one) - not in
parallel.
For a multi-threaded/forked web server, this isn't an issue as each
HTTPS request goes to a separate thread/process being handled
independently. Which also reduces the risk of slowness and lagging -
unless all the allowed configured threads/processes are occupied and busy.
I hope this explains better why you can't compare HTTPS' TLS
implementation directly with OpenVPN's implementation. As it truly
cannot be compared 1:1.
--
kind regards,
David Sommerseth
OpenVPN Technologies, Inc
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
