mirror of
https://github.com/beyondx/Notes.git
synced 2026-02-08 04:44:51 +08:00
42 lines
3.8 KiB
Plaintext
42 lines
3.8 KiB
Plaintext
Content-Type: text/x-zim-wiki
|
|
Wiki-Format: zim 0.4
|
|
Creation-Date: 2011-10-12T19:25:44+08:00
|
|
|
|
====== SSL and TLS ======
|
|
Created Wednesday 12 October 2011
|
|
|
|
SSL stands for "**Secure Sockets Layer;**" TLS, for "**Transport Layer Security.**" SSL was developed by Netscape for use in __securing HTTP.__ That is still its principal use, although there is nothing specific to HTTP about SSL. When a browser accesses a URL which begins with__ "https"__, it __speaks HTTP over an SSL connection__. TLS is the name of the IETF protocol standard that grew out of __SSL 3.0__, and is documented by RFC 2246. We will use the term "TLS."
|
|
|
|
TLS has goals and features similar to those of the SSH Transport and User Authentication protocols. It provides a single,__ full-duplex byte stream__ to clients, with cryptographically assured privacy and integrity, and optional authentication. It differs from SSH in the following principal ways:
|
|
|
|
TLS server authentication is optional: the protocol supports fully anonymous operation, in which neither side is authenticated. Such connections are inherently vulnerable to man-in-the-middle attacks. In SSH-TRANS, server authentication is mandatory, which protects against such attacks. Of course, it is always possible for a client to skip the step of verifying that the public key supplied by the server actually belongs to the entity the client intended to contact (e.g. using the **/etc/ssh_known_hosts** file). However, SSH-TRANS at least demands going through the motions.
|
|
Both client and server authentication are done with X.509 public-key certificates. This makes TLS a bit more cumbersome to use than SSH in practice, since it requires a functioning __public-key infrastructure (PKI)__ to be in place, and certificates are more complicated things to generate and manage than SSH keys. However, a PKI system provides scalable key management for your trouble, which SSH currently lacks.
|
|
TLS does not provide the range of client authentication options that SSH does; public-key is the only option.
|
|
TLS does not have the extra features provided by the other SSH component: the SSH Connection Protocol (SSH-CONN). SSH-CONN uses the underlying SSH-TRANS connection to provide muliple logical data channels to the application, as well as support for remote program execution, terminal management, tunnelled TCP connections, flow control, etc.
|
|
|
|
|
|
|
|
====== SSL: ======
|
|
A public key cryptography tunneling protocol, and various internet
|
|
services can be piped through it. Ports 115, 563, 995, 465, and 443 are
|
|
the standard ports for __SSL-encrypted FTP, NNTP, POP3, SMTP, and HTTP__
|
|
sessions. Some clients have SSL support built-in (all web browsers, and
|
|
some NNTP and e-mail clients). Clients without built-in SSL support can
|
|
still use SSL via "**SSL proxies**" like Stunnel (i.e. Eudora@127.0.0.1 -->
|
|
127.0.0.1:stunnel_port --> smtp.myisp.com:465). To my knowledge, there
|
|
is __no username/password __authentication built into the SSL protocol itself.
|
|
Authentication is left up to the daemon receiving __SSL connections.__ I.e.,
|
|
if connecting to an NNTP server on port 563, user authentication would
|
|
happen *inside the SSL tunnel* with the normal NNTP "AUTHINFO" commands,
|
|
just like if a non-SSL port 119 NNTP connection were underway.
|
|
|
|
====== SSH: ======
|
|
Another public key cryptography tunneling protocol like SSL, but
|
|
unlike SSL, SSH__ has username/password authentication__ is built into it.
|
|
All SSH-capable clients connect to port 22 (SSH) on the destination server
|
|
to negotiate the username/password stage, and if successful, the clients
|
|
then tell the SSH daemons what it wants to connect to. I.e., an SSH-aware
|
|
SMTP client would connect to mail.myisp.com:22, send my username/password
|
|
to the SSH daemon, and then tell the SSH daemon "I want you to connect to
|
|
mail.myisp.com:25 on my behalf and proxy it through to me".
|