Add New Notes

2026-06-16 15:08:37 +08:00 · 2012-08-08 14:26:04 +08:00
commit 5ef7c20052
2374 changed files with 276187 additions and 0 deletions
--- a/Zim/Utils/SSH_and_SSL/SSH_and_SSH详解.txt
+++ b/Zim/Utils/SSH_and_SSL/SSH_and_SSH详解.txt
@@ -0,0 +1,221 @@
+Content-Type: text/x-zim-wiki
+Wiki-Format: zim 0.4
+Creation-Date: 2011-10-12T18:26:50+08:00
+
+====== SSH and SSH详解 ======
+Created Wednesday 12 October 2011
+http://www.ws-ping.com/support/ws_ftp/guide/wsftpug76/08sslutil.html
+Chapter 8: Security
+
+This chapter describes the two security protocols found in WS_FTP Pro: SSL and SSH. It also explains how to configure WS_FTP Pro to use these protocols to make secure connections.
+
+===== SSL =====
+
+SSL (Secure Socket Layer) is a protocol for encrypting and decrypting data sent across direct internet connections. When a client makes an SSL connection with a server, all data sent to and from that server is encoded with a complex mathematical algorithm that makes it extremely difficult to decode anything that is intercepted.
+
+The following is a step by step illustration of how SSL works.
+
+**Step 1. **The client makes the initial connection with the server and requests that an SSL connection be made. 
+客户端发起SSL连接请求。
+
+**Step 2.** If the server is properly configured, the server will send to the client its certificate and public key.
+ 服务器支持SSL的话就返回自己的证书(证书里包含有自己的公钥)。
+
+**Step 3. **The client compares the certificate from the server to a **trusted authorities database**. If the certificate is listed there, it means the client trusts the server and will move to step 4. If the certificate is not listed there, the user must **add the certificate** to the trusted authorities database before going to step 4. 
+客户端会对服务器发过来的证书进行比较验证(一般是将签名该证书的根证书与本地信任的根证书列表进行查找比较)，若失败，则客户端必须将该证书添加到本地数据库后才能继续与服务器建立连接。
+
+**Step 4. **The client uses that public key to encrypt a session key and sends the session key to the server. If the server asks for the client's certificate in Step 2, the client must send it at this point.
+客户端用收到证书里的公钥加密一个标识这次连接会话的key然后将其发送给服务器。如果服务器要求验证客户端的证书，这时客户端也必须同时将自己的证书发给服务器。
+
+**Step 5. **If the server is **set up** to receive certificates, it compares the certificate it received with those listed in its trusted authorities database and either accepts or rejects the connection.
+服务器同样对客户端发过来的证书进行比较验证。
+
+If the connection is rejected, a **fail message** is sent to the client. If the connection is accepted, or if the server is not set up to receive certificates, it decodes the session key from the client with its own private key and sends a success message back to the client, thereby opening a secure data channel.
+如果服务器接受连接，会用自己的私钥对客户端发过来的session key进行解密，如果成功则发送一条消息给客户端，安全通道正式建立。
+
+===== PS： =====
+**SSL一般用于client-server环境，而且对服务器的认证是必须的，但是对客户端的认证是可选的，这是因为一般是对客户端发往服务器的信息(如帐号、密码等)进行加密。**
+
+The key to understanding how SSL works is in understanding the parts that make SSL itself work. The following is a list of these parts and the role each plays.
+
+**Client.** In this case, the client is WS_FTP Pro.
+
+**Certificate.** The Certificate file **holds** the identification information of the client or server. This file is used during **connection negotiations** to identify the parties involved. In some cases, the client's certificate must **be signed** by the server's certificate in order to open an SSL connection. Certificate files have the__ .crt__ ending.
+
+**Session Key. **The session key is what both the client and the server use to encrypt data. It is created by the** client**.
+客户端创建该key然后用服务器的公钥对其加密后发给服务器，服务器用自己的私钥对其解密。成功后用客户端的公钥(若有的话)对其加密，然后发给客户端，客户端用自己的私钥对其解密验证。
+
+**Public Key. **The public key is the **device **with which the client encrypts a session key. __It does not exist as a file, but is a by-product of the creation of a certificate and private key. __Data encrypted with a public key can only be decrypted by the private key that made it.
+
+**Private Key.** The private key decrypts the client's session key that is encrypted by a public key. The private key file has the __.key __ending. Private keys should NEVER be distributed to anyone.
+
+**Certificate Signing Request.** A certificate signing request is generated each time a certificate is created. This file is used when you need to have your certificate signed. Once the Certificate Signing Request file is signed, a new certificate is made and can be used to replace the unsigned certificate.
+证书签名请求文件是和证书文件一起生成的，而且是配对使用的。该文件一旦被签名，就会重新生成一个新的已签名证书。
+
+===== How to make an SSL connection =====
+
+To make an SSL connection with a server** configured for SSL**.
+
+* Be sure to select the Secure (SSL) option when you follow the directions for configuring a site.
+* After you click Connect, WS_FTP Pro tells the server that you want to make an SSL connection. The server then transmits to you an **identifying certificate**, letting the client know **who the server is.** If that certificate is already listed in your __Trusted Authority database__, the connection is made.
+* If that certificate is not listed as a trusted authority, the Non-Trusted Authority dialog box appears. 
+      对于服务器发送的证书，客户端不信任的话，必须手动将其添加到本地数据库中。
+* Select the option you need and click OK. If the server does not require a certificate to be returned, the secure connection will be established. All data transmitted between you and the server will be encrypted. 
+
+If the server you are attempting to make a connection to asks WS_FTP Pro to send back a certificate, follow the direction for Client Certificate Verification.
+
+===== Client Certificate Verification 服务器对客户端证书认证 =====
+
+If the server you are attempting to make a connection to __requires__ your client to send an identifying certificate back to the server, you must:
+
+* Configure the site with the Secure (SSL) option selected.
+* Create a certificate. Refer to the section "Generating a Certificate" for more information.
+       手动生成一个证书。
+* Send the **Certificate Signing Request file **to your server administrator.
+      将和该证书同时生成的证书签名请求文件发送给系统管理员，请求其签名。
+* Once the server administrator **signs **the Certificate Signing Request, it will be sent back to you.
+      管理员对该文件签名后会生成一个新的证书(以前的可以不使用)会发送给客户端
+* When you receive the file, follow the directions for "Selecting a Certificate", selecting the new certificate to go in the Certificate box.
+      客户端可以使用该证书连接服务器
+* Connect to the server. 
+
+===== Generating a Certificate =====
+
+To create an SSL certificate:
+
+    From the Options menu, select Configure SSL. The **SSL Utilities** window appears.
+    Click the Certificate Creation tab. 
+
+    Enter a name in the **Certificate Set Name box**. This will be the name of the certificate that is generated by WS_FTP Pro.
+    Click the Browse (...) button in the **Output Location box** to select the folder you want the certificate created in.
+    Enter information in all of the **Certificate Information boxes**:
+
+ 
+
+ //  City/Town.// City or town where you are located. (Ex. Augusta)
+
+//    State/Province. //State or Province where you are located. (Ex. Georgia)
+
+//    Organization.// Company or individual user name.
+
+//    Common Name.// This can be either the **name of the person** creating the certificate or the** fully qualified domain name **of the server associated with the host.
+
+    __Pass Phrase. __Pass phrase that is to be used to **encrypt the private key**. It is important to remember this pass phrase. The pass phrase can be any combination of words, symbols, spaces, or numbers.
+
+//    Pass Phrase Confirmation.// Re-enter the same pass phrase as above.
+
+//    Country. //The country you are in. This must be a valid two letter country code. (Ex. US)
+
+//    E-mail.// E-mail address of the person the certificate belongs to.
+
+//    Unit. //Name of organizational unit. (Ex. Research and Development)
+
+    After all of the boxes are filled in correctly, click Create to generate the __keys, certificate, and certificate signing request.__ If all of the boxes are not filled in, you cannot create the certificate. 
+
+If you are creating a certificate to be used by WS_FTP Pro, you should send the **certificate signing request **(by E-mail) to your server administrator. If they require it, they will sign the certificate and return it to you. The returned certificate should be the one you identify in the Certificate Selection tab.
+
+===== Selecting a Certificate =====
+
+The Certificate Selection tab is used to choose__ which private key and certificate __you want to use during __SSL connection negotiations__. If a new certificate has not been created, follow the directions for "Generating a Certificate".
+
+To select an SSL Certificate:
+
+    Click the Browse (...) button next to the** Private Key box** to select the private key you want to use during SSL negotiation.
+    Click the Browse (...) button next to the** Certificate box **to select the certificate you want to use during SSL negotiation. The certificate you use must have been created using the key you selected for the Private Key box.
+
+	注意：私钥和证书必须要配对使用。
+    Enter the __pass phrase associated with that certificate__ in both the Pass Phrase and the Pass Phrase Confirmation boxes. A pass phrase can be any combination of words, symbols, spaces or numbers. It is case sensitive and must be written exactly the same way each time it is used.
+
+    Without the correct pass phrase in both boxes, the certificate and private key cannot be verified and the selection cannot be saved.
+    Click Apply to save your entries.
+
+    Clicking the Reset button erases what you have done since the last time new settings were applied.
+
+====== Trusted Authorities ======
+
+The Trusted Authorities tab stores **a list of certificate names** that are recognized by WS_FTP Pro.
+
+Certificate Display:
+
+**Issued To.** Who the certificate was issued to.
+
+**Issued By.** Who the certificate was__ signed__ by.
+
+**Expires**. Date on which the certificate expires.
+
+==== Adding a Certificate(添加本地信任的证书，一般为根证书) ====
+
+To add a certificate to the database:
+
+    Click the Import button and select the path and file name for the certificate. The **Add Certificate? dialog box** appears. 
+
+    Review the information on that dialog box and click Yes to add the certificate to the database. 
+
+===== Exporting a Certificate =====
+
+To export a certificate from the** Trusted Authorities database**:
+
+    Select the certificate you want to copy out of your database.
+    Click the Export button.
+
+    Select the folder you want to copy the certificate to and enter the name you want to save the certificate file as.
+    Click OK. 
+
+===== Removing a Certificate =====
+
+To remove a certificate:
+
+    Select the certificate to be removed.
+    Click Remove.
+    A warning appears advising you to export the certificate before you remove it. Removing the certificate deletes the certificate file.
+    Click OK to remove the certificate. 
+
+====== Non-Trusted Certificate ======
+
+When you connect to a server using the SSL connection option, that server sends you a certificate. __If that certificate is not listed on the Trusted Authority tab, or if it was not signed by a certificate on this list__, this dialog box appears.
+
+Certificate Information:
+
+**Issued To. **Name of the person or company who the certificate belongs to.
+
+**Issued By. **Name of the person or company who signed the certificate.
+
+**Active From. **The date on which this certificate was activated.
+
+**Expires On. **The date the displayed certificate will no longer be a valid certificate.
+
+Options
+
+Allow this connection only. If this option is selected, the connection will be made, but WS_FTP Pro will still not recognize the certificate as a trusted authority. The next time you attempt to connect to this server, this dialog box appears once again.
+
+**Trust this certificate.** If this option is selected, the connection will be made and the certificate will be added to the trusted authority database in the Trusted Authority tab, so future connections can be made without you being prompted.
+
+Do not allow this connection. If this option is selected, the connection will be terminated.
+
+====== SSH ======
+
+SSH (Secure Shell) is a security protocol that allows you to make a secure connection to a server that has the **SSH and SFTP** (Secure File Transfer Protocol) protocols installed. Where FTP servers usually `listen' on port 21 for connection, SSH servers use port **22**.
+
+__Where SSL attempts to make a connection with unencrypted channels, SSH encrypts all communications to and from the client and server.__
+
+When an SSH connection is made, SFTP is the protocol that is used to perform all tasks on that single secure connection.
+
+===== How to make an SSH connection =====
+
+Making an SSH connection requires little additional configuration to new or your existing site profiles.
+
+When creating a new site profile through the New Site Wizard, simply change the Server Type to SFTP/SSH when prompted by the wizard.
+
+If editing an existing site profile:
+
+    Select the site from the configured sites list.
+    Click the Edit button.
+    Click the Advanced tab.
+    In the Server type pull-down, select SFTP/SSH.
+    Click OK. 
+
+When you use that profile to make a connection, the client will automatically attempt to make an SSH connection on port 22 of that server.
+
+===== SSL vs. SSH =====
+
+With both SSL and SSH, it is up to the administrator of the server you are trying to make a connection with to tell you which server type is being run at that address. If you do not know, and attempt to make an SSL connection or an insecure connection to an SSH server, the connection will fail, even if you change the port to 22 in the Site Profile. 
--- a/Zim/Utils/SSH_and_SSL/SSH_tunnel_tips.txt
+++ b/Zim/Utils/SSH_and_SSL/SSH_tunnel_tips.txt
@@ -0,0 +1,90 @@
+Content-Type: text/x-zim-wiki
+Wiki-Format: zim 0.4
+Creation-Date: 2011-04-06T18:29:40+08:00
+
+====== SSH tunnel tips ======
+by pluskid, on 2009-08-14, in Tool     11 comments
+http://blog.pluskid.org/?p=369
+
+以前接触 SSH 的时候我就在文档上见过 SSH tunnel 相关的东西，然而当时没有怎么看明白，也就一直没有深究，直到最近需求越来越多了，才终于发现这个东西原来这么有用，于是记录在此。
+
+**SSH tunnel** 主要有三种，一种是** dynamic application-level port forwarding **，可以用来作为 SOCKS proxy ，通常翻墙就是用的这种端口映射；一种是** Local Forwarding** ，主要用于提供常规的加密隧道，例如让 IMAP 协议通过这个加密隧道，避免密码在网络上被人监听到；一种是 **Remote Forwarding** ，可以用于逆向穿透 NAT 。其实，另外还有一种专门为 X 打造的 **X11 Forwarding** ，一般不会用到，Linux 下远程登录通常不会需要开启 X 程序，或者有其他更好用的方法，因此我们这里并不打算介绍这个。
+
+首先我们来假定一个网络环境：有一个防火墙，在防火墙内部有一个机器 H ，通过 NAT 访问 Internet ，并且在防火墙外的 Internet 上的机器 T 上**有一个 ssh 帐号**，而另一台 Internet 上的机器 S 则是一台公共服务器，例如 Google 的服务器。如下图所示：
+						{{./ssh.png}}
+												ssh
+首先来说 Local Forwarding ，相关的文档上都用的是阅读邮件这个经典的例子：用户在 T 上有一个 IMAP 服务器，本来他可以直接连接到 T:143 上阅读邮件的，但是这是未加密连接，如果你的 IMAP 服务器是用明文密码验证的方式的话，就很糟糕了，这样你的密码很容易被别人窃听到。这个时候 SSH 隧道就出来了，通过如下命令可以建立一个 SSH 隧道：
+
+__ssh -L 9143:localhost:143 T__
+
+#这里的local意思是，本地的ssh客服端程序把由本地127.0.0.1:9143端口发出的数据通过与T间的ssh加密隧道转发到远程的143端口,由于指定了localhost，故是T上的143端口。
+
+首先不看参数，这个命令是发起一个 ssh 连接到主机 T ，然后选项 -L 表示 Local Forwarding ，**9143 表示本地（亦即 H）的端口，然后 localhost:143 则是远程所对应的主机和端口**。这样一来，你在 H 上连接端口 9143 ，就相当于你在 T 上连接 localhost:143 一样，SSH 建立的隧道会帮你在两个主机间传递信息。现在只要配置 H 上的邮件客户端去连接 localhost:9143 ，就能通过加密的方式访问到 T 上的 localhost:143 这个邮件服务器了。注意两个主机上的 localhost 的区别。
+
+当然隧道并不限于 localhost(即远程的运行着sshd的服务器T) ，如果你愿意，可以做这样一个映射：
+
+__ssh -L 9999:www.google.com:80 T__
+#由于指定了www.google.com:，本地的ssh客户端进程会把发往本地127.0.0.1：9999端口的数据通过加密隧道传给T，然后T的sshd服务进程会把这个请求转发到www.google.com:80(sshd会根据传给他的**应用层协议类型**也就是目的端口号和IP或主机名来判断)，并将返回的数据通过隧道传到H的127.0.0.1：9999端口。
+
+这样，你可以在 H 的浏览器里输入 localhost:9999 访问到 Google 了。注意到 H 和 T 之间的数据传输是加密的，所以，如果 H 是处在伟大的局域网内，而 T 是在外部的话，可以通过这样的方法来访问 Google 而不受防火墙的限制。不过这种方法**每个本地端口只能映射到一个远程主机的固定端口**，很不方便。
+
+
+要用作代理通常还是使用 __dynamic application-level port forwarding__ 的方式，如下：
+
+__ssh -D 9999 T__
+
+#这时本地的ssh客户端进程担任了一个socks服务器的角色，他监听本地的127.0.0.1:9999端口，把从该端口发出的数据通过隧道传到T的sshd进程，然后sshd再根据请求数据中的信息(IP地址或主机名加端口号)发送相应的请求然后把返回的数据通过隧道传给客户端的127.0.0.1：9999
+
+这样建立起来的隧道实际上是一个 __SOCKS 代理__，当然要使用 **SOCKS 代理需要客户端能够支持才行**，比如在 Firefox 中，只要在代理处填写 localhost:9999 并勾选 SOCKS5 代理即可。另外，还可以使用诸如 ProxyChains 之类的程序让本身不支持 SOCKS 代理的程序能够“透明地”使用 SOCKS 代理，不过我并没有尝试过，不知道稳定性如何。
+
+最后要介绍的就是 Remote Forwarding 了，也就是ssh客户端帮助远程主机转发，首先看命令吧：
+
+__ssh -R 9923:10.13.21.88:23 T__
+
+-R的意义是：在远程主机T上指定一个sshd监听的端口号如9923然后他向该端口发的数据会通过隧道被H的ssh客户端接收，然后ssh客户端会将请求数据转发给本地(不一定是本机)的主机和端口号。
+
+这里 10.13.21.88 是 H 所在的局域网里的一台主机，23 是 telnet 默认的端口，其实这就是浙大飘渺水云间 bbs （亦即“88”）的校内地址了，由于是在局域网内，Internet 上的 T 是访问不到它的，现在 H 建立了一个到 T 的 Remote Forwarding ，对应之前的 Local Forwarding 的意思，应该能猜到了吧？现在在 T 上可以通过访问 localhost:9923 来上 88 了。 :D 换句话说，在 T 上访问 localhost:9923 相当于在 H 上访问 10.13.21.88:23 ，这成了一个反向的隧道。
+
+综上，Local 和Remote都是相对与本地H的__ssh客户端__进程来说的，前者是将发往本地指定端口上的数据通过隧道发往sshd服务器，sshd再做处理。后者是本地的ssh客户进程将远程sshd传过来的数据(sshd监听并转发特定端口)转发到相应的主机。
+
+另外，上面三种 Forwarding 默认建立的 socket 都是监听本机的 **loopback** 地址的，这样外面的机器是不能访问这个端口映射的。对于最后那个飘渺水云间的隧道来讲，默认情况下，T 虽然可以通过 localhost:9923 来上 88 ，但是 S 却不能通过 T:9923 来访问到，而是会得到一个 Connection Refused 的错误，这样做也是为了安全起见，不过，如果确实想要让__这个隧道可以从其他主机访问到的话__，上面三个命令都可以在映射参数前面再加一个地址参数。例如飘渺水云间的那个映射其实等价于：
+
+ssh -R localhost:9923:10.13.21.88:23 T
+
+把 localhost 改成 * 就可以让其他机器也访问到了（注意加上引号以防止 shell 把星号给展开了）：
+
+__ssh -R '*:9923:10.13.21.88:23' T__
+
+唔，还有一点要说明的是，对于 -L 和 -D 来说，都是这样就可以了，而 -R 则还需要远程的 sshd 配置一下__ GatewayPorts __选项，默认情况下是 no ，这样会无视掉客户端的请求，强制 bind 到 loopback 地址上，而 yes 则相当于强制 * ，如果设置成 clientspecified 则允许客户端来选择(注意，-R选项时的远程sshd监听的端口号是由ssh客户端在命令行上指定的)。因此在 /etc/ssh/sshd_config 文件里添加这样一行：
+
+__GatewayPorts clientspecified__
+
+再重启 ssh 服务即可。虽然学校提供了 RVPN 可以从校外访问到校内的资源，但是并没有提供 Linux 下的解决方案。在没有校外独立 IP 的情况下用这样的方法在外面访问学校的资源就变得非常有用了。要是 -D 也能有一个对应的 Reverse 的方案也许会更方便一些，不过也许可以用 -R 和 -D 桥接一个：
+
+H$ ssh -D 9999 localhost
+H$ ssh -R 9999:localhost:9999 T
+
+在 T 上使用 localhost:9999 作为 SOCKS 代理，而该端口的数据会被 forward 到 H 上的 localhost:9999 ，那里是实际的 SOCKS 代理服务器。不过我没有实际测试过是不是真的可以用。 :p
+
+最后再说一句，**FTP 是另一个经典的明文传输密码的协议，但是它却没法通过 SSH 隧道使用，因为它需要另外打开一个 socket 来传输数据**，这时就不在 SSH 的接管范围之内了，我想这也许是 SFTP 这个东西诞生的直接原因吧。其实使用了 -R 的端口映射之后，要 scp 回来是一件很容易的事，例如：
+
+H$ ssh -R 9922:localhost:22 T
+T$ scp foo.txt -P 9922 localhost:~/
+
+可以将 T 上的 foo.txt 拷贝回 H 的主目录中。当然，如果只是为了做一个端口映射，可不必打开一个远程 shell ，只要再为 ssh 加上 -Nf 参数即可，具体是什么意思自己 man 吧。它会在后台运行，一直等待到对应隧道端口的连接。需要注意的是，在有了第一个连接之后，如果连接数降为零了，它会自动退出。所以我通常还是会打开远程 shell ，不过使用 screen 把它放在后台去，就不会妨碍了，需要的时候可以调出来，也可以方便地控制它什么时候退出。 :)
+
+最后，在客户端的 ~/.ssh/config 里加入
+
+ServerAliveInterval 180
+
+这样可以防止长时间的 idle 导致 ssh 连接被自动断开。
+
+    不知道 iptables ，做端口转发？SSH 主要是做隧道了，要两台机器参与，端口转发的话是同一台机器双 IP 的情况吧？
+
+    关于用reversed tunneling做rvpn
+    往往情况是T也不是公网ip 例如在firewall后面
+    那H就不能ssh T了
+
+    结果是需要一个middleman，H,T都能访问到 那可以连上
+    可是谁能提供一个。。。
+   
--- a/Zim/Utils/SSH_and_SSL/SSH_tunnel_tips/ssh.png
+++ b/Zim/Utils/SSH_and_SSL/SSH_tunnel_tips/ssh.png
--- a/Zim/Utils/SSH_and_SSL/SSH和SSL比较.txt
+++ b/Zim/Utils/SSH_and_SSL/SSH和SSL比较.txt
@@ -0,0 +1,44 @@
+Content-Type: text/x-zim-wiki
+Wiki-Format: zim 0.4
+Creation-Date: 2011-10-12T19:31:46+08:00
+
+====== SSH和SSL比较 ======
+Created Wednesday 12 October 2011
+
+====== 一、SSH介绍 　什么是SSH？ ======
+
+　 　传统的网络服务程序，如：ftp、pop和telnet在本质上都是不安全的，因为它们在网络上用明文传送口令和数据， 别有用心的人非常容易就可以截 获这些口令和数据。而且，这些服务程序的安全验证方式也是有其弱点的， 就是很容易受到“中间人”（man-in-the-middle）这种方式的攻 击。所谓“中间人”的攻击方式， 就是“中间人”冒充真正的服务器接收你的传给服务器的数据，然后再冒充你把数据传给真正的服务器。 服务器和你之间的数 据传送被“中间人”一转手做了手脚之后，就会出现很严重的问题。
+
+　　SSH的英文全称是Secure Shell。通过使用SSH，你可以把所有传输的数据进行加密，这样“中间人”这种攻击方式就不可能实现了， 而且也能够防止DNS和IP欺骗。还有一个 额外的好处就是传输的数据是__经过压缩__的，所以可以加快传输的速度。 SSH有很多功能，它既可以代替telnet，又可以为ftp、pop、甚至ppp提 供一个安全的“通道”。
+
+　　最初SSH是由芬兰的一家公司开发的。但是因为受版权和加密算法的限制，现在很多人都转而使用__OpenSSH__。 OpenSSH是SSH的替代软件，而且是免费的，可以预计将来会有越 来越多的人使用它而不是SSH。
+
+　　SSH是由客户端和服务端的软件组成的，有两个**不兼容的版本分别是：1.x和2.x**。 用SSH 2.x的客户程序是不能连接到SSH 1.x的服务程序上去的。OpenSSH 2.x同时支持SSH 1.x和2.x。
+
+===== SSH的安全验证是如何工作的 =====
+
+　　从客户端来看，SSH提供两种级别的安全验证。
+
+　　第一种级别（基于__口令__的安全验证）只要你知道自己帐号和口令，就可以登录到远程主机。所有传输的数据都会被加密， 但是不能保证你正在连接的服务器就是你想连接的服务器。可能会有别的服务器在冒充真正的服务器， 也就是受到“中间人”这种方式的攻击。
+
+　 　第二种级别（基于__密匙__的安全验证）需要依靠密匙，也就是你必须为自己创建一对密匙，并把__公用密匙放在需要访问的服务器__上。 如果你要连接到SSH服务器 上，客户端软件就会向服务器发出请求，请求用你的密匙进行安全验证。服务器收到请求之后， 先在你在该服务器的**家目录下寻找你的公用密匙**，然后把它和你__发送过来的公用密匙__进行比较。如果两个密匙一致， 服务器就用公用密匙加密“质询”（challenge）并把它发送给客户端软件。 客户端软件收到“质询”之后就可以用你的私人密匙解密再把它发送给服务器。
+
+　　用这种方式，你必须知道自己密匙的口令。但是，与第一种级别相比，第二种级别不需要在网络上传送口令。
+
+　　第二种级别不仅加密所有传送的数据，而且“中间人”这种攻击方式也是不可能的（因为他没有你的私人密匙）。 但是整个登录的过程可能需要10秒。
+
+====== 二、SSL介绍（Secure socket Layer & Security Socket Layer） ======
+
+　　一个应用程序的安全需求在很大程度上依赖于将如何使用该应用程序和该应用程序将要保护什么。不过，用现有技术实现强大的、 一般用途的安全通常是可能的。认证就是一个很好的示例。
+
+　 　当顾客想从 Web 站点购买某个产品时，顾客和 Web 站点__都要__进行认证。顾客通常是以提供__名字和密码__的方式来认证他自己。 另一方面，Web 站 点通过交换一块签名数据和一个有效的__ X.509 证书__（作为 SSL 握手的一部分）来认证它自己。 顾客的浏览器验证该证书并用所附的公用密钥验证签 名数据。一旦双方都认证了，则交易就可以开始了。
+
+　　安全套接字层（Secure Sockets Layer （SSL）） ，SSL 是一种安全协议，它为网络（例如因特网）的通信提供私密性。SSL 使应用程序在通信时不用担心被窃听和篡改。 SSL 实际上 是共同工作的两个协议：“SSL 记录协议”（SSL Record Protocol）和“SSL 握手协议” （SSL Handshake Protocol）。“SSL 记录协议”是两个协议中较低级别的协议，它为较高级别的协议， 例如 SSL 握手协议对 数据的变长的记录进行加密和解密。SSL 握手协议处理应用程序凭证的交换和验证。
+
+　　当一个应用程序（客户机）想和另一个应用程 序（服务器）通信时，客户机打开一个与服务器相连接的套接字连接。然后， 客户机和服务器对安全连接进行协商。作为协商的一部分，服务器向客户机作自我认 证。客户机可以选择向服务器**作或不作**自我认证。 一旦完成了认证并且建立了安全连接，则两个应用程序就可以安全地进行通信。按照惯例，我将把发起该通信的 对等机看作客户机， 另一个对等机则看作服务器，不管连接之后它们充当什么角色。
+
+　　名为 A 和 B 的两台对等机想安全地进行通 信。在我们简单的 p2p 应用程序的环境中，对等机 A 想查询对等机 B 上的一个资源。 每个对等机都有__包含其专用密钥的一个数据库（名为 keystore）和包含其公用密钥的证书__。密码保护数据库的内容。 该数据库还包含一个或多个来自被信任的对等机的自签名证书。 对等机 A 发起这 项事务，每台对等机相互认证，两台对等机协商采用的密码及其长度并建立一个安全通道。完成这些操作之后， 每个对等机都知道它正在跟谁交谈并且知道通道是 安全的。 SSL (Secure socket Layer)安全套接层协议主要是使用公开密钥体制和X.509数字证书技术保护信息传输的机密性和完 整性， 它不能保证信息的不可抵赖性，主要适用于点对点之间的信息传输，常用Web Server方式。
+
+　　安全套接层协议（SSL，Security Socket Layer）是网景（Netscape）公司提出的基于WEB应用的安全协议，它包括：服务器认证、 客户认证（可选）、SSL链路上的数据
+
+　 　完整性和SSL链路上的数据保密性。对于电子商务应用来说，使用SSL可保证信息的真实性、 完整性和保密性。但由于SSL不对应用层的消息进行数字签 名，因此不能提供交易的不可否认性，这是SSL在电子商务中使用的最大不足。 有鉴于此，网景公司在从Communicator 4.04版开始的所有浏 览器中引入了一种被称作“表单签名（Form Signing）”的功能， 在电子商务中，可利用这一功能来对包含购买者的订购信息和付款指令的表单进行 数字签名，从而保证交易信息的不可否认性。综上所述， 在电子商务中采用单一的SSL协议来保证交易的安全是不够的，但采用"SSL+表单签名"模式能够 为电子商务提供较好的安全性保证。
--- a/Zim/Utils/SSH_and_SSL/SSL_and_TLS.txt
+++ b/Zim/Utils/SSH_and_SSL/SSL_and_TLS.txt
@@ -0,0 +1,41 @@
+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".