SSH的全称为Secure Shell Protocol，是一种在互联网上提供安全远程登录（取代telnet)及其它安全网络服务（取代FTP）的协议，只要在客户端连接时选择SSH协议即可。对于服务器端的配置，Red Hat Enterprise Linux默认开启了SSH服务，对于配置文件的详细解释，可以参考下面两篇文章。

sshd_config配置 详解

sshd_config 中文手册

由于SSH的传输加密特性，还可以用来做安全隧道

SSH tunnel tips 

IBM developworks上的这一篇 实战 SSH 端口转发 介绍的更为详细，而且有“X 协议转发实例分析”，在维护UNIX/LINUX时可以更方便。

安全隧道的实际用途之一么，当然是用来翻墙。

Firefox + Autoproxy + Tor 使用详解（转载）

MyEnTunnel+FireFox+FoxyProxy 通过SSH帐号翻墙教程

如何使用代理服务器

当然用PPTP建个VPN也是可以的

利用低端VPS开设VPN翻墙

科学松鼠会的一篇公钥安全机制与宫爆鸡丁的故事不错

扯远了，最后付一篇

Unix/Linux 系统自动化管理: 远程登录篇

本文版权所有 © 2010 Xin LI <delphij@FreeBSD.org> 保留所有权利

原文链接 《安全：该做什么和不该做什么》

非商业转载请注明出处http://blog.delphij.net/， 谢绝商业转载。

安全不能建立在"别人不知道"的基础上

"别人不知道"是一种非常常见的安全假象，举例来说，一种自己设计的山寨加密算法、一个系统中一般人不知道的位置等等，都属于这一类。

将安全建立在"别人不知道"的基础上是非常危险的。首先它会给设计者和用户带来"安全"的幻像，这会直接导致与系统交互的人放松警惕；其次，这样的设计往往留有"后门"，甚至是设计者不知道的后门（因为往往他们并不对这类设计进行充分的、专业的审计），容易被攻击者利用；最后，这种做法存在第三方泄密问题，即，使用这种系统的人，需要提防设计系统的人被其他人买通并泄漏一些秘密的情况。

延缓攻击的手段不能用来阻挡攻击

有许多延缓攻击的手段，例如改变服务的端口（比较常见的如将 ssh 改为 tcp/22 以外的端口），或禁止服务程序显示自己的版本等等，或仅仅简单地启用防火墙，这些手段起到的作用只是延缓攻击，而不应作为一种安全屏障。对于多层次式的安全设计来说，采取这些措施有助于提高检测到入侵的机会，但是它们本身并不会提高安全性。

与前一种情况类似，这种做法也只是让管理员放松警惕。例如以 ssh 为例，有人认为将端口改为一个非知名端口可以避免相关的攻击，但事实是，攻击者依然可以利用 ssh 实现或协议设计中存在的一些漏洞来攻破系统。拥有特定资源的攻击者甚至不需要直接对目标系统实施攻击。在较复杂的攻击手段中，包括简单的 port knocking 一类的保护手法，都可以使用类似分组重放这样的方法来逐步攻破。

采用层次式的安全设计

所谓层次式的安全设计，说的是在一套安全系统中包含不同层次的、存在层次式监控关系的安全结构。例如，将本地包含执行文件的那些文件系统通过一定的方式导出给监控网段的机器，就可以让那些机器在攻击者不知情，或至少不太容易注意到的情况下对入侵进行检测；通过将一些重要日志发到以不同的访问控制机制，甚至不同网络协议的记录设备上，则可以有效地检测入侵者的入侵行为，并为日后的分析留下更多的有用信息。

层次式安全在现实中也有应用。例如产品的质检，除了制造商自己进行的质量控制之外，有时分销商或政府也会进行一些抽样的检查。我们注意到，这些设计中的一个重要的特点是在不同的系统中使用不同的访问控制逻辑。例如，日志服务器必须从特定的客户端，甚至只能从某些隔离的内网登录。此时，延缓攻击的手段可以作为它的一项辅助设施，即其目的并不是阻止攻击，而是吸引攻击者在攻击目标上花费更多的时间，从而帮助入侵检测机制更容易地检测这些攻击。

不要轻信任何东西，包括X.509证书

安全系统的设计者必须对安全有全面的理解和认知。有一句很著名的话叫做 In God we trust, all others must submit an X.509 Certificate，需要注意的是，这里说的是 must submit，并没有说 submit 了就可以 trust 了。

和前面所说的层次式安全设计类似，我们的一个基本假定应该是，一个安全系统中的任何参与者，无论是用户还是计算机或程序，都是可能存在弱点的。安全系统，或用户，都不应轻信任何东西，例如，在特权隔离 (Privilege Separation) 这样一种设计中，特权进程除了完成那个非特权的子进程的请求之外，还有一个任务是维护一个"理性状态机"（Sanity DFA），这个状态机的作用是检测非特权进程的异常状况，如果发生这样的情况，则特权进程有拒绝提供服务，并杀掉非特权进程的责任。作为用户，对于系统给出的响应，除了验证对方的证书之外，也应有常识性的了解和适当的判断。

不要把安全建立在不靠谱的基础设施上

举个现实生活中的例子，修一座桥，结果水泥标号不够；修一座楼，结果钢筋用竹签代替，有可能稳当吗？

然而在安全系统的设计中，很多人却往往忽视这样显而易见的问题。比较典型的就是许多网站所采用的所谓"安全控件"的技术。每一个这样的新设施，都意味着新增的攻击面和一组可能可以利用的新漏洞。

在一个安全系统中，防守的一方一定是弱势群体，因为他们必须按照一定的规矩去设计系统；而攻击者则可以采用最便宜的攻击方式。时刻牢记，在你花费时间去加强系统中最坚固的部分的时候，你的对手则正在靠近这个系统中最薄弱的环节，甚至可能是在你不知道的情况下！

下面是一些典型的不靠谱安全设施：

• 自己设计的算法。（公开的算法经过了更多的专业人士的验证；而自己设计的算法则没有，每个人的知识面都会有些局限，即使第一流的密码学设计者也可能设计出糟糕的算法，因此同行的验证很重要）
• 监控键盘的驱动程序。（这类做法不仅不能对安全产生助益，反而会给其他木马带来监控用户键盘，从而攫取其他机密信息的便利）。
• 基于明文的通讯协议。（当数据需要经过不受控制的网络节点的时候，端对端加密是非常重要的）。

操作复杂不等于安全

一些安全措施在实施了之后，用户可能会发觉与之前相比会带来一些不便。有些不便可能是无法避免的，但这并不意味着，使用的时候给用户带来不适的安全设施就一定会提高安全性。

举例来说，一些银行在登录时，会在用户输入用户名之后，先显示一张用户自己定义的图片，然后再让用户输入密码。这种设施本身并没有改善任何安全性，因为中间人攻击仍然可以获得那个图片，更糟糕的是，由于看到了希望看到的那张图片，用户反而会对这个网站产生安全幻觉。

而另一种做法则是给用户一个小的token，这个token能够根据网站和token之间共享的信息和用户自己的密码来计算出一个登录用的一次性密码。拿到这个一次性密码的攻击者，并没有很好的办法再次使用这个密码来做别的事情。

代码开放和安全是不是一回事

许多人认为，开放源代码的东西更安全一些。这种说法并不完全正确。还有一些人认为，因为代码大家都可以看到，因此开放源代码的东西更安全，事实上，后面这种看法完全是逻辑混乱。

举个例子，面对来要求审计账目的税务局，一个CEO的回答是，我的账目绝对没有问题，因为我这家公司上上下下200多人都可以随时去看。毫不意外地，这个审计师决定自己再看一遍，因为这是一家广告公司，而"能看"和"看过的人都是内行"以及"有多少内行看过"也是完全不同的概念。

在选择一个解决方案的时候，如果一定要参考其他人的意见的时候，一定要看这个意见是来自什么人。开放源代码的产品一样有可能会存在漏洞，看它代码的人很可能并不是很有安全方面知识和经验的人，有这些经验的人可能在看其他的开放源代码，甚至不开放源代码的产品，等等。真正重要的是，找一个值得信任的专业人士去做这样的评估，而不是仅仅看一个和安全与否关系不大的指标就匆忙决定。

使用公开的、经过验证的安全算法和协议

算法和协议是实际应用中的安全系统中最关键的两个部件。经过验证的、公开的算法和协议有这样一些无法替代的好处：

• 设计它们的坏人有足够的专业知识。
• 试图攻击它们，并且也有足够专业知识的坏人已经证明，攻破它们需要的代价大到不值得从这个方面去突破它们。
• 坏人之间为了证明自己做了充分的对抗性的同僚复审。
• 它们被破解的时候，你可能不是最先知道这件事的，但是也不会是最需要担心这件事的人。
• 最重要的一点：设计一个自己破解不了的东西很容易，而设计一个 别人 破解不了的东西很难。我要提醒读者的是，你需要的是别人破解不了你的系统，而不仅仅是你自己破解不了。

避免同一类型的弱点

攻击者在攻击的时候，往往会采用最"便宜"的方法去进行。例如，在发现一个由于程序设计问题而导致的安全漏洞时，除了修正这个问题本身之外，还应对系统中可能存在类似问题的其他环节进行类似的代码审计。对于开源项目来说这一点尤其重要。

例如，如果OS允许在地址0附近映射内存页，则由于欠锁一类原因导致的竞态条件所导致的可能就不仅仅是崩溃了。这类问题的典型用例是先将自己的代码映射到地址0附近，然后设法触发内核的一个可能导致空指针引用的函数指针调用，这样系统将会在内核的上下文运行那些代码（说明：出于性能考虑，一般来说内核并不会切换到一个完全不同的地址空间去运行）。尽管修正竞态条件本身很重要（例如FreeBSD SA 09:13.pipe），但通过禁止在地址0附近映射内存页，可以将这一类型的潜在漏洞全部由特权提升降级为崩溃或死锁，因此也就有了 FreeBSD EN 09:05.null 所做的改动。

避免过度设计，优先改进最薄弱的环节

过度设计是许多工程师会遇到的问题。例如，在内网交换机上传输加密数据，在多数情况下都是不必要的（听不到发到其他节点的包，而听包本身所需要的权限已经足够做其他事情）。

攻击者不需要遵循任何规则，而防守者则必须遵守一定的标准。因此，作为原则，防守的一方应假定攻击者会找到系统中最薄弱的环节，或者说，站在攻击者的角度去思考从什么地方去攻陷系统，并加强系统中最薄弱的那些环节。

不过，想要避免这些设计问题，必须拥有许多相关的知识和经验。

今天先写到这里，改天继续总结。

本文为个人收藏及技术传播

虽然我们的网络在公开场合下自称是“开放”的互联网，但实际情况却不是这样的，例如前几天，已经有两个同事咨询过我，如何使用代理服务访问Facebook，我发现其过程还是挺多的，与其我一步步讲给他们听，不如写一个教程，这样他们也更能理解和操作。下面我就介绍一下我是怎么使用代理服务器的，算是一篇科普教程吧。

前面一段是科普教程，如果你只关心如何使用代理，可以直接跳到“如何使用SOCKS代理服务器”这一段。

什么是代理服务器

代理服务器（Proxy Server）是网上提供转接功能的服务器，在一般情况下，我们使用网络浏览器直接去连接其他Internet站点取得网络信息时，是直接联系到目的站点服务器，然后由目的站点服务器把信息传送回来。代理服务器是介于客户端和Web服务器之间的另一台服务器，有了它之后，浏览器不是直接到Web服务器去取回网页而是向代理服务器发出请求，信号会先送到代理服务器，由代理服务器来取回浏览器所需要的信息并传送给你的浏览器。

比如你想访问的目的网站是A，由于某种原因你不能访问到网站A或者你不想直接访问网站A（这样通过代理服务器网站A，对网站A而已可以隐藏你自己的身份，也就是不知道是谁访问的网站，而认为是代理服务器访问的），此时你就可以使用代理服务器，在实际访问网站的时候，你在浏览器的地址栏内和你以前一样输入你要访问的网站，浏览器会自动先访问代理服务器，然后代理服务器会自动给你转接到你的目标网站。

代理服务器的作用

提高访问速度：通常代理服务器都设置一个较大的缓冲区，当有外界的信息通过时，同时也将其保存到缓冲区中，当其他用户再访问相同的信息时，则直接由缓冲区中取出信息，传给用户，以提高访问速度。

隐藏真实身份：上网者也可以通过代理服务器隐藏自己的真实地址信息，还可隐藏自己的IP，防止被黑客攻击。

突破限制：有时候网络供应商会对上网用户的端口，目的网站，协议，游戏，即时通讯软件等的限制，使用代理服务器都可以突破这些限制。

代理服务器主要类型

HTTP代理：最简单的一种代理形式，能够代理客户机的HTTP访问，上网浏览网页使用的都是HTTP协议，通常的HTTP代理端口为80、3128或8080端口。

SOCKS代理：SOCKS代理与HTTP等其他类型的代理不同，它只是简单地传递数据包，而并不关心是何种应用协议，既可以是HTTP协议，也可以是FTP协议，或者其他任何协议，所以SOCKS代理服务器比其他类型的代理服务器速度要快得多。SOCKS代理又分为SOCKS4和 SOCKS5，二者不同的是SOCKS4代理只支持TCP协议（即传输控制协议），而SOCKS5代理则既支持TCP协议又支持UDP协议（即用户数据包协议），还支持各种身份验证机制、服务器端远程域名解析（解决DNS污染就靠这个了）等。SOCK4能做到的SOCKS5都可得到，但SOCKS5能够做到的SOCKS则不一定能做到。目前SOCKS5是最常用的一种SOCKS代理。

如何使用HTTP代理服务器

HTTP代理服务器的设置方法，对于IE和FireFox设置略有不同。设置前需要先找一些可用的免费代理服务器地址。

IE的设置是这样的，打开IE浏览器，选择菜单栏的“工具/Internet选项…”。

这时候分两种情况，对于ADSL拨号用户来说，选择一个网络连接后，点“设置”，如下图所示，选中代理服务器，填入地址和端口号。

对于局域网用户来说，需要点“局域网设置”，如下图所示，选中代理服务器，填入地址和端口号。

FireFox的设置和IE类似，打开FireFox浏览器，选择菜单栏的“工具/选项…”。

这时选择“高级/网络”，点设置，就出现下面的界面，就可以进行代理服务器的设置了，选中“手动配置代理”，然后填写代理服务器的地址和端口。

如何使用SOCKS代理服务器

这里就到重点内容了，SOCKS代理是目前功能最为全面，使用最为稳定的代理服务器，我目前上网就只用SSH搭建SOCKS代理服务器上网，访问网络没有任何限制。下面我就着重讲一下如何使用SOCKS代理服务器。

用SSH搭建SOCKS代理上网，建议使用Firefox浏览器，因为Firefox支持SOCKS代理远程域名解析，而IE只能通过类似SocksCap这样的第三方软件实现，不是很方便。

配置Firefox浏览器

在Firefox设置SOCKS远程域名解析，主要是为了防止DNS污染，具体设置方法是，在Firefox地址栏中，输入 about:config ，按确认，修改里面的一项数值，改成 network.proxy.socks_remote_dns=true 就可以了。

然后，打开FireFox浏览器，选择菜单栏的“工具/选项…”。选择“高级/网络”，点设置，就出现下面的界面，就可以进行代理服务器的设置了，选中“手动配置代理”，然后在SOCKS主机上，填写代理服务器的地址127.0.0.1，端口1080，SOCKS类型选择“SOCKS V5”，这时Firefox就配置结束。

设置SSH

配置好了Firefox，就该配置SSH了，安全外壳协议（Secure Shell Protocol / SSH）是一种在不安全网络上提供安全远程登录及其它安全网络服务的协议。常用的SSH工具有开源软件PuTTY，支持SSH远程登录的主机可以实现socks5代理服务器的功能，不过在PuTTY中没有配置文件，需要手动设置才能实现，且无法保存，而PuTTY完整版自带的pLink可以实现命令行方式调用PuTTY实现SSH的加密通道。

具体的方法是，去PuTTY官方网站下载pLink这个文件，pLink的调用参数是：plink -C -v -N -pw 密码 -D 本地端口 远程用户@IP或域名:远程希望打开的端口。

新建一个文件，写入以下内容，另存为pLink.bat批处理文件，并放在Putty的安装目录内。

plink -N Username@sshServer -pw Password -D 127.0.0.1:1080

请将Username sshServer Password三处改为用户自己登陆SSH服务器的用户名、服务器地址和密码。这个SSH帐号可以通过多种方法获得，例如用户购买了某些国外主机空间或VPS就会有SSH帐号，或者在淘宝网也有SSH帐号出售，我自用的SSH帐号是用每年100美元购买虚拟主机时赠送的，通常SSH帐号的价格大约是每年几十元人民币左右，也有少量国外网站提供免费的SSH帐号。

执行这个批处理文件，保持其窗口开启，一旦关闭窗口代理便失效。然后打开已经配置好127.0.0.1:1080的Socks5代理的Firefox浏览器，就可以使用SOCKS代理服务器上网了。

其他设置技巧

为了方便代理服务器的快速切换，我建议安装一个名为QuickProxy的FireFox代理服务器扩展，可以实现一键切换代理功能，QuickProxy安装后在状态栏有一个按钮，点击后可以启用、关闭Firefox浏览器的默认代理设置，可以快速在代理和非代理之间切换，很方便。界面如下图所示。

设置完成了之后，你就可以自由自在地在开放的互联网上傲游了。根据我的使用经验，基于SSH的SOCKS代理稳定、快速、功能全面，是值得推荐的代理方法，使用过程中流量需要自己把控，我个人觉得其浏览体验要远远高于其他代理软件。

随着这次Google退出中国市场，本文可能会成为未来网民常用的上网技巧之一。

作者： Jeff Moser
译者： 马国耀
原文链接：http://www.infoq.com/cn/articles/HTTPS-Connection-Jeff-Moser

当你在浏览了一个网站上面的商品之后，点击“继续并结帐”时会发生什么？本文即将对（浏览器）与Amazon建立安全连接的整个过程中最初的若干毫秒进行分析。当你点击继续按钮时一个新的页面将被加载：

在短暂的220毫秒内，发生了很多有趣的事情，Firefox修改了地址栏的颜色，并在其右下角放置了一个锁状的图标。在我最喜爱的网络工具Wireshark以及略微修改的Firefox调试版的帮助下，我们可以对正在发生的事情看个究竟。

根据RFC 2818协议的规定，Firefox明白“https”意味着它应该连接Amazon.com的443端口：

大多数人将HTTPS和SSL(Secure Sockets Layer)联系起来，SSL是Netscape公司在90年代中期发明的。随着时间的推移这种说法就渐渐变得不准确了。由于Netscape失去了市场份额，它将SSL的维护工作移交给因特网工程任务组（IETF）。第一个后Netscape版本被重新命名为安全传输层协议（TLS），TLS1.0是在1999年1月份发布的。由于TLS诞生都10年了， 所以真正的“SSL”传输其实是几乎见不到。

Client Hello

TLS将所有的网络传输打包成不同的“记录”类型。我们看到从浏览器出来的第一个字节是一个十六进制（hex）字节0×16=22，这说明它是一个“握手”记录：

后面的两个字节是0×0301，意味着它的版本是3.1，事实上TLS1.0就是SSL3.1。

“握手”记录被分解成若干消息。第一个就是“Client Hello”消息（0×01）。这里面有很重要的几点：

· 随机数：

前面的四个字节是当前的协调世界时（Coordinated Universal Time，UTC），它的格式是Unix时间戳，也就是从1970年1月1日起到此刻所经历的秒数。在本例中的该数字是0×4a2f07ca。跟随其后是28字节的随机数，它将在后面使用。

· 会话标识（session id）：

在这里它是空值或者是null。如果在几秒前该浏览器曾连接过Amazon.com，它就可能继续使用前面的会话，而不需要重新执行整个“握手”过程。

· 密码套件：

它是浏览器所支持的密码算法的一个列表。最上面的是一个很强大的组合“TLS_ECDHE_ECDSA_与_AES_256_CBC_SHA，下面还有该浏览器支持的另外33个选择。如果现在不明白它们的含义也不必担心，后面你将会发现Amazon并没有选择最上面的强大组合。

· server_name extension:

通过它告诉Amazon.com，浏览器正要连接https://www.amazon.com/。这样做非常方便，因为TLS“握手”发生在所有的HTTP传输之前 。HTTP协议中有一个“Host”头， 这就允许了Internet托管公司出于成本的考虑将上百个网站绑定在同一IP 地址上。传统意义上SSL要求每一个地址有一个不同的IP，而这个扩展就使得服务器能够正确响应浏览器所请求的（服务器）证书。最后注意一点，对于 IPv4的地址这一扩展的有效期大概能再多一周左右。

Server Hello

对应于Client Hello，Amazon.com也返回一个“握手”记录，它是两个庞大的数据包(2,551字节)。该记录的版本号是0×0301，也就意味这Amazon支持我们使用的TLS1.0版本的请求。这个记录分成三个子消息，他们包含着一些有趣的信息。

1. "Server Hello" 消息（2）：

o 我们得到服务器返回的四字节的Unix时间戳以及28字节的随机数，它也将在后面使用（译注：注Clien Hello是发了一个随机数，这两个随机数将用于产生最后的对称密钥）。

o 一个32字节的会话标识，有了它，随后重连服务器就不需要再执行一个完整的握手过程了。

o 从我们提供的34个可选的密码套件中，Amazon选择的套件“TLS_RSA_WITH_RC4_128_MD5”（0×0004）。也就是说它将使用“RSA” 公钥算法来验证证书以及交换密钥，用RC4加密算法对数据进行加密，使用MD5哈 希算法来校验消息内容。后面会对它们做详细介绍。我个人认为Amazon选择这个密码套件的原因是出于自私的考虑（译注：这里说“自私”的意思 是，Amazon出于性能的考虑，降低了安全的强度）。这个套件是这34个套件中消耗CPU最少的一个，因此Amazon选择它就是为了节省一些CPU来 处理更多的用户连接。还有一个不大可能的原因是他们要特别地向Ron Rivest致敬，这个套件中所用到的三个算法都是他发明的。

2. 证书消息（11）：

这个巨大的消息占据了2464个字节，它是一个证书，客户端用它对Amazon进行认证。它并不是什么花哨的玩意，通过浏览器就可以看到它的大部分内容：

3. “Server Hello 结束”消息（14）：

这是一个0字节的消息，它告诉客户端“hello”过程已经完成，也就意味着服务端将不验证客户端的证书。

校验证书

浏览器必须要确定它是否要信任Amazon.com，在这里是通过证书判断的。它检查Amazon的证书并且检查现在的时间是否在证书的有效期之内，该有效期规定的是“不能早于”2008年8月26日且“不能晚于”2009年8月27日。此外，它还要确保该证书的公钥已经被授权在进行密钥交换的过程中使用。

为什么我们应该相信这个证书呢？

在证书上附有一份“签名”，这个签名事实上是一个big-endian（译注：Big-Endian和Little-Endian是一种二进位资料储存或传输的格式，Big-Endian的最高位字节在最前头，而Little-Endian的最高位字节在最后面）格式的长整型数：

任何人都有可能发给我们这些字节，为什么我们要相信这个签名呢？为了回答这个问题，有必要先到这里mathemagic land去速成一些相关知识：

穿插：简短的，不那么可怕的RSA向导

有时候人们想知道数学和编程有何联系。证书就是应用数学的一个非常实际的例子。Amazon的证书告诉我们应该用RSA算法来校验其签名。RSA是MIT的教授Ron Rivest，Adi Shamir和Len Adleman在70年代创造出来的，他们三人创造了一个巧妙的方法将2000多年来 数学发展的思想汇合起来形成了一个漂亮而简单的算法：

首先选择两个很大的质数“p”和“q”，并对他们求积得到“n=p*q”。接下来，取一个较小的“e”作为指数，它用作“加密指数”，而对e的进行特殊的逆反函数计算所得到的“d”作为“解密指数”。然后将“n”和“e”公开出去，而对“d”要保密，对于“p”和“q”你可以把它们扔掉，也可以像“d”一样保密起来。真正重要的要记住“d”和“e”是相互的逆反。

现在，如果你有一些消息，那么你只需要将该消息的字节翻译成一个数“M”，若要对这个消息进行“加密”形成“密文”的话，你就这么计算：

C ≡ Me (mod n)

它意思是先求“M”的“e”次方，然后对它应用模数“n”求余。举个例子，11AM +3 hours ≡ 2 （PM）（mod 12 hours）。接收者知道（解密用的）“d”，而“d”可以对已加密的消息进行反转并还原消息：

Cd ≡ (Me)d ≡ Me*d ≡ M1 ≡ M (mod n)

另一件有意思的事情是拿着“d”的人可以对一个文档进行签名，其做法是文档“M”求“d”次幂然后应用模数“n”求余数“S”：

Md ≡ S (mod n)

这种做法成立的原因是“签名者”将“S”，“M”，“e”以及“n”公开出去，任何人都可以通过这样一个简单的计算来验证“S”是否由“签名者”所 签（译 注：因为每个“e”都是某个签名者所独有的，而“e”和“d”是成对出现的，所以签名者用自己的“d”签名，只能拿这个“d”所对应的“e”才能还原消 息，这就到了签名的作用）：

Se ≡ (Md)e ≡ Md*e ≡ Me*d ≡ M1 ≡ M (mod n)

像RSA这样的公钥密码算法经常被称之为“非对称”算法，因为加密的密钥（本例子中的“e”）和解密的密钥是不相同的（本例子中是“d”）。对所有的数应用“mod n”的目的是使攻击者不可能使用简单的技术（如过去我们使用的对数）破解它。RSA的神奇之处是你可以很快计算/加密C ≡ M^e (mod n)，而在不知道“d”的情况下计算/解密C^d ≡ M (mod n)是非常困难的。如前面所说，“d”来自于对“n”的因子分解，而“n”来自于“p”和“q”，求解“d”是一件复杂的事情。

签名验证

在现实世界里使用RSA时应该谨记的重要的一点是，前文提到的所有数字都应是很大的数，只有这样才能保证，即使用目前最好的算法也 很难攻破上述算法。到底多大才算很大的数呢？Amazon.com的证书是由“VeriSign Class 3 Secure Server CA.” 签名的。从这个证书中我们可以看出，VeriSign所使用的模数“n”是一个2048比特长的数字，表示成10进制数的长度是617位：

1890572922 9464742433 9498401781 6528521078 8629616064 3051642608 4317020197 7241822595 6075980039 8371048211 4887504542 4200635317 0422636532 2091550579 0341204005 1169453804 7325464426 0479594122 4167270607 6731441028 3698615569 9947933786 3789783838 5829991518 1037601365 0218058341 7944190228 0926880299 3425241541 4300090021 1055372661 2125414429 9349272172 5333752665 6605550620 5558450610 3253786958 8361121949 2417723618 5199653627 5260212221 0847786057 9342235500 9443918198 9038906234 1550747726 8041766919 1500918876 1961879460 3091993360 6376719337 6644159792 1249204891 7079005527 7689341573 9395596650 5484628101 0469658502 1566385762 0175231997 6268718746 7514321

（如果你要试图从这个“n”中找到“p”和“q”那就祝你好运，假如你能找到他们，那么你能产生像真的一样的VeriSign证书了）

VeriSign的“e”的值是2^16 + 1 = 65537。当然，他们对相应的“d”保密，也许被放在一个安全的硬件设备上，由视网膜扫描机和武装部队保护着。在签名之前，VeriSign要通过现实世界的“握手”来验证Amazon.com声明的证书内容，包括审查他们的很多商务文档。一旦VeriSign对这些文档满意了，他们使用SHA-1哈希算法对包含所有声明的证书进行计算获得一个哈希值。在Wireshark中看到整个证书的样子如下图“signedCertificate”部分所示：

上面的说法（整个证书如同signedCertificate所示）说有点用词不当，因为证书的实际含义是签名者将要进行签名的部分，而不是已经包含了签名信息的字节。

实际的签名，也就是“S”，是Wireshark包中简单地称为“encrypted”的部分（见上图）。如果我们求“S”的“e”次幂（“e”是VeriSign公开的），然后在对该结果取模“n”并得到余数，那么我们得到的“已解密”十六进制签名是：

0001FFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFF00302130 0906052B0E03021A 05000414C19F8786 871775C60EFE0542 E4C2167C830539DB

基于PKCS #1 v1.5标准， 最开始的字节是“00”，它“保证了加密块被转换成整数之后，大小不会超过模数”。第二个字节“01”说明这是一个私钥操作（如，它是一个签名）。后面是 一大堆“FF”，用他们填充这个结果，使之足够大。填充字节以“00”结束，后面跟的是"30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14"，PKCS #1 v2.就是这样来指定SHA-1哈希算法。最后的20个字节是对“signedCertificate”部分的SHA-1哈希摘要。

因为解密的值有着正确的格式并且最后的字节和我们独立计算得到的哈希值相同，我们可以认为这就是由拥有“VeriSign Class 3 Secure Server CA”私钥的人所签名的，而我们隐含地信任只有VeriSign知道这个私钥“d”。

但我们为什么要信任它呢？因为在信任链上已经没有更高级别了。

最上层的“VeriSign Class 3 Public Primary Certification Authority”是自签名的。这个证书自从网络安全服务（Network Security ServicesNSS）库中certdata.txt的1.4版本之后就已经被嵌入Mozilla的产品中作为一个隐含的受信证书。它是由NetScape的Robert Relyea在2000年9月6日登记进去的，当时他还留下以下评注：

"用这个框架来收集其他网络安全服务，它包括这一个“实时的”certdata.txt ，里面存放了那些我们已经获得许可权可以推向开源的证书（当我们从所有者那里获得许可权之后，会有更多的证书加入这个文档中）”

由于该证书的有效期范围是从1996年1月28日到2028年8月1日，所以这个决定是意义深远的。

Ken Thompson在他的“Reflection on Trusting Trust”中解释的非常好，你最终不得不隐式地信任某人。在这个问题上别无选择。本例中我们隐含地信任Robert Relyea做了个好的选择，我们也希望Mozilla的内建证书策略对其他的内建证书也是合理的。

这里要记住的一点是所有这些证书和签名都简单地用来形成一个信任链。在公共网络中，在你还未上任何网站之前，Firefox就已经隐含地信任了VeriSign的根证书。在一个公司内，你可以创建你自己的根证书CA，并将它安装在每个人的电脑上。

或者，你还可以付钱给VeriSign这样的公司并把所有的证书信任链的工作交给它。证书用来通过可信的第三方（这里是VeriSign）建立信任 关系。如果你可以安全地和别人共享密钥，比如“在某人耳边轻声告诉他一长串密码”，那么你就可以使用预共享密钥（PSK，Pre-shared Kay）认证来建立信任关系。TLS对此也有扩展，比如TLS-PSK，以及我本人所喜欢的TLS的安全远程密码扩展。然而，这些扩展没能被广泛地使用和支持，所以他们通常是不切实际的。此外，这些方法增加了负担，它们要求必须通过安全的方式交换密钥，而这比通过TLS来建立信任连接的负担更重（要不然我们何不都这么用呢？）。

我们要做的最后的检查是验证证书上的主机名是否是我们期待访问的。 Nelson Bolyard 在 SSL_AuthCertificate 函数中的注释是这样解释的：

/* 证书是没问题的。这是SSL连接的客户端。
*现在要检查证书中的名字和所期待的主机名是否一致。
*注意：这是我们防范中间人（Man-In-The-Middle）攻击的唯一途经*/

这个检查防范了中间人攻击，因为我们隐含地相信拥有证书的人不会干坏事，例如，只有它真是Amazon.com，它才会对一个证书签名说它是Amazon.com。如果一个攻击者能够通过类似 DNS缓存破坏的技术修改我们的DNS服务器，你可能被蒙蔽了，以为自己正访问正确的网站（如Amazon.com），因为你的浏览器的地址栏看起来就是这个网站。这最后的检查就隐含地信任证书的授权机构可以防止坏事的发生。

Pre-Master Secret

现在我们已经验证了Amazon.com的那些声明，并且知道其公开的加密指数“e”和模数“n”。任何在网络上侦听的人当然也知道这两个数（这点 很明显，因为我们是通过Wireshark获取它们的，别人也可以）。现在我们要创建一个攻击者或偷听者不能辨别的随机密钥，这件事做起来不像听起来那么 简单。在1996年，研究者发现Netscape Navigator1.1仅使用三个数据源来作为他们的伪随机数生产器的种子（PRNG），它们是：当前时间，进程号和父进程号。研究显示，这些“随机”源并不那么随机，而且相对比较容易被猜出来。

由于其他的所有东西都是从这三个“随机”源产的，在1996年当时的机器上可能只需25秒中就可以“攻破”SSL“安全”。如果你还不相信寻找随机数是件困难的事，只要问问Debian OpenSSL维护者就知道了。如果随机数搞乱了，那么基于它之上的所有安全都是可疑的。

在Windows上，用于加解密的随机数是通过调用CryptGenRandom函数对来自125个源的抽样数据求hash值产生的。Firefox将该函数产生的随机数和它自己的函数产生的比特码一起作为伪随机数生成器的种子。

虽然这个48字节的“pre-master secret”随机数并不直接使用，但是保证其私密性是非常重要的，因为很多东西都是由它而来的。毫无疑问，Firefox让我们很难看到这个数。我不得不编译了一个调试版本并设置SSLDEBUGFILE和SSLTRACE两个环境变量才能看到它。

在本次会话中，SSLDEBUGFILE中显示的这个pre-master secret是这样的：

4456: SSL[131491792]: Pre-Master Secret [Len: 48]
03 01 bb 7b 08 98 a7 49 de e8 e9 b8 91 52 ec 81 …{…I…..R..
4c c2 39 7b f6 ba 1c 0a b1 95 50 29 be 02 ad e6 L.9{……P)….
ad 6e 11 3f 20 c4 66 f0 64 22 57 7e e1 06 7a 3b .n.? .f.d"W~..z;

需要指出的是这并非全是随机数， 按约定，最前面的两个字节是TLS版本（03 01）。

密钥交换

现在要把这个密钥传给Amazon.com。由于Amazon选择的是“TLS_RSA_WITH_RC4_128_MD5”，我们将使用RSA算 法来做这件事。输入消息可以是正好48字节的pre-master secret，但是公钥密码学标准（PKCS）#1，RFC1.5 要求用一些随机数来填充这个数使其长度等于模数的长度（1024比特，或者128字节）。这样做就使得攻击者更难找出我们的pre-master secret了，另外，万一有人做傻事，比如重用相同的密钥，它还为我们提供最后一层保护。通过这样一填充，即使我们重用密钥，偷听者在网络上两次看到的 数也是不一样的。

又，因为Firefox让我们很难看到这些随机数，我不得不在填充函数中加入一些调试语句才能看到发生的事情：

在这次会话中，填充后的消息如下所示：

00 02 12 A3 EA B1 65 D6 81 6C 13 14 13 62 10 53 23 B3 96 85 FF 24 FA CC 46 11 21 24 A4 81 EA 30 63 95 D4 DC BF 9C CC D0 2E DD 5A A6 41 6A 4E 82 65 7D 70 7D 50 09 17 CD 10 55 97 B9 C1 A1 84 F2 A9 AB EA 7D F4 CC 54 E4 64 6E 3A E5 91 A0 06 00 03 01 BB 7B 08 98 A7 49 DE E8 E9 B8 91 52 EC 81 4C C2 39 7B F6 BA 1C 0A B1 95 50 29 BE 02 AD E6 AD 6E 11 3F 20 C4 66 F0 64 22 57 7E E1 06 7A 3B

Firefox拿这个数进行计算“C ≡ M^e (mod n)”，得到的数是我们在客户密钥交换记录中所看到的

最后Firefox发出最后一条没加密的消息，一个“Change Cipher Spec”记录：

Firefox使用这种方式通知Amazon，它将使用前面协商好的密钥来加密下一条消息。

生成Master Secret

如果前面所有事情都正确完成，则双方（且只有这双方，客户端和服务端）现已知道这个48字节的pre-master secret。从Amazon的角度来看这里有一个很小的信任问题：pre- master secret只包含客户端生成的比特位，他们没有考虑到服务端或者我们前面所提到的那些随机数（译注：Client hello和Server hello过程中产生的随机数）。我们将通过计算“master secret”来解决这个问题。根据规约，应该这么计算：

master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random)

“pre_master_secret”是客户端之前发送的；“master secret”用的是一个字符串的ASCII值（例如：“6d 61 73 74 65 72 …”）。然后我们将本文最开始看到的ClientHello和ServerHello发送的随机数拼接起来。

PRF是一个“伪随机数函数”，这个函数很聪明，在规约中也有定义。它使用基于哈希的消息验证码（HMAC）的MD5和SHA-1两种哈希函数将密钥，ASCII字符以及我们给的种子结合起来。对每个哈希函数发送一半的输入。说它聪明的原因是即使面对MD5和SHA-1的弱点，它的防攻击能力还很强。这个过程可以自我反馈并不停地循环，而且我们要多少字节就能生成多少。

依照这个过程，我们获得以下48字节的“master secret”：

4C AF 20 30 8F 4C AA C5 66 4A 02 90 F2 AC 10 00 39 DB 1D E0 1F CB E0 E0 9D D7 E6 BE 62 A4 6C 18 06 AD 79 21 DB 82 1D 53 84 DB 35 A7 1F C1 01 19

多个密钥的生成

现在双方都有了“master secrets”，规约描述了我们如何生成会话所需的所有的密钥，我们需要使用PRF函数来创建一个“key block”，然后从这个块中提取所需的密钥：

key_block = PRF(SecurityParameters.master_secret, "key expansion", SecurityParameters.server_random + SecurityParameters.client_random);

“key_block”被用来提取以下密钥：

client_write_MAC_secret[SecurityParameters.hash_size]
server_write_MAC_secret[SecurityParameters.hash_size]
client_write_key[SecurityParameters.key_material_length]
server_write_key[SecurityParameters.key_material_length]
client_write_IV[SecurityParameters.IV_size]
server_write_IV[SecurityParameters.IV_size]

由于这里使用的是序列密码而非分组密码（如高级加密标准AES），所以不需要初始向量（Initialization VectorsIV），而只是双方各需要一个16字节（128比特）的消息验证码（Message Authentication Code MAC），这是因为指定的MD5哈希摘要大小是16字节。另外，RC4加密算法使用的16字节的密码也是双方都需要的。最后，我们需要key block中的2*16 + 2*16 = 64个字节：

运行PRF，我们得到：

client_write_MAC_secret = 80 B8 F6 09 51 74 EA DB 29 28 EF 6F 9A B8 81 B0
server_write_MAC_secret = 67 7C 96 7B 70 C5 BC 62 9D 1D 1F 4A A6 79 81 61
client_write_key = 32 13 2C DD 1B 39 36 40 84 4A DE E5 6C 52 46 72
server_write_key = 58 36 C4 0D 8C 7C 74 DA 6D B7 34 0A 91 B6 8F A7

准备加密！

客户端发出的最后一条“握手”消息是“Finished message”。 这个消息非常巧妙，它不仅能证明没有人篡改了握手过程，还能证明我们确实知道密钥。客户端将所有的“握手”消息放入一个 “handshake_messages”缓存区，然后使用伪随机函数，“client finished”字符串以及MD5和SHA-1哈希运算后“handshake_messages”计算出12字节的“verify_data”：

verify_data = PRF(master_secret, "client finished", MD5(handshake_messages) + SHA-1(handshake_messages)) [12]

我们在这个结果的前面加上一个记录头字节“0×14”指明“完成”和长度字节“00 00 0c”指明我们将发送12字节的“verify data”。然后，像所有接下来的加密消息一样， 我们要确保解密后的内容没有被篡改。因为选择使用的密码套件是TLS_RSA_WITH_RC4_128_MD5，所以我们将使用MD5哈希函数。

有些人一听到MD5就感到恐慌，因为它存在一些弱点，我原先也很不提倡使用它。然而，TLS很聪明，他并不直接使用MD5，而使用它的HMAC版本。TLS是这样使用MDB进行计算的：

HMAC_MD5(Key, m) = MD5((Key ⊕ opad) ++ MD5((Key ⊕ ipad) ++ m)

（⊕指的是异或（XOR），++指的是拼接，“opad”是一串“5c 5c … 5c”字节，“ipad”是另一串“36 36 … 36”）。

这里我们对以下内容进行计算：

HMAC_MD5(client_write_MAC_secret, seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length + TLSCompressed.fragment));

也许你已经看到，我们加入了一个序列号（“seq_num”）和明文消息（这里被称为TLSCompressed）的一些其他属性。序列号可以迷惑 攻击者，他可能会在中途把一个先前加密的消息插入。如果他这么干，则序列号一定和我们所期待的不一样，这就保护了我们不受攻击者们扔消息的攻击。

剩下就是加密消息了。

RC4加密算法

从前文已知双方协商的密码套件是TLS_RSA_WITH_RC4_128_MD5。这就意味着我们将使用Ron’s Code #4 (RC4)对传输信息进行加密。Ron Rivest开发了基于256字节的密钥生成随机数的RC4加密算法。这个算法非常简单，以至于几分钟内你就可以记住它。

RC4从创建一个256字节的数组“S”开始，并从0到255对其进行填充。然后从“S”的第0位开始循环，将“S”和密钥中的字节进行混合，这样做是为了创建用于产生“随机”数的状态机。为了生成随机数，我们将“S”数组进行洗牌（译注：参考百度百科RC4）

图形化描述是这样的：

对一个字节进行加密，我们对伪随机字节和要加密的字节进行异或运 算。记住将一个比特和1进行异或的话是使这个比特反转（译注：0^1=1, 1^1=0）。因为前面产生的是随机数，所以大约会有一半的比特码会被反转，这种随机的比特反转在加密数据时非常有效。你已经看到，这并不复杂，而且运行 起来很快。我想这也许就是Amazon用它的原因吧。

回想一下，我们有“client_write_key”和“server_write_key”。这意味这我们需要创建两个RC4实例，一个用于加密浏览器发送的消息，另一个用于解密服务器返回的消息。.

“client_write”最前面的随机字节是“E 20 7A 4D FE FB 78 A7 33 …”，如果我们用这些字节和未加密的消息头（经查证，该消息的字节为“4 00 00 0C 98 F0 AE CB C4 …”）进行异或运算的话，我们将得到在Wireshark中看到的已加密的部分：

服务器做的事情几乎一样。它发出一条“Change Cipher Spec”消息，然后发出的“Finished Message”消息，这条消息包括所有的“握手”消息，以及解密的客户端发过来的“Finished Message”，这也向客户端表明了服务端可以正确解密客户端发过来的消息。

欢迎回到应用层！

现在，220毫秒过去了，我们最终为应用层准备好了，现在我们可以发送通过TLS层使用RC4的写实例加密过的普通HTTP消息，也可以解密服务端RC4写实例发过来的消息。此外，TLS层还会通过计算消息内容的HMAC_MD5哈希值来校验每一条消息是否被篡改。

至此，“握手”过程已经完成，现在TLS记录的content type变成23（0×17）。加密的数据流以“17 03 01”开始，这几个字节表明了记录类型和TLS版本，后面是包含了HMAC哈希的加密数据。

对如下明文的加密：

GET /gp/cart/view.html/ref=pd_luc_mri HTTP/1.1
Host: www.amazon.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.10) Gecko/2009060911 Minefield/3.0.10 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
…

将得到下面这些字节：

剩下的唯一有趣的事是每个消息的序列号是依次递增的，现在是1（下一个消息将会是2，以此类推）。

服务端做的事情是一样的，不过它使用“server_write_key”这个密钥。我们看到它的响应消息，包括泄露秘密的应用数据头。

这个消息解密后得到：

HTTP/1.1 200 OK
Date: Wed, 10 Jun 2009 01:09:30 GMT
Server: Server
…
Cneonction: close
Transfer-Encoding: chunked

这是一个普通的HTTP返回消息，它包含一个非描述性“Server: Server”HTTP头和一个来自Amazon负载均衡器的“Cneonction: close”头，显然拼写有误。

TLS就在应用层之下。HTTP服务器上的软件可以就像发送非加密数据一样工作，而唯一的区别是它们（指软件）将数据写到一个库，由这个库统一做加密。OpenSSL是TLS的一个非常流行的开源库。

在双方发送和接受加密数据的过程中，链接一直保持活动状态，直到任何一端发出一条“closure alert”消息并接着关闭连接。如果在断开后的很短时间内重连，则可以重用前面协商好的密钥（前提是服务器还缓存着他们），这样就不需要公钥操作，否则，就需要重新执行一次完全的握手过程。

应用数据消息可以是任何信息，这点很重要。“HTTPS”特别的唯一原因是因为Web太流行了，还有其他基于TCP/IP的协议运行在TLS之上。例如，TLS也用于FTPS和SMTP的安全扩展。使用TLS肯定比你自己发明解决方案要好，另外，使用经得起仔细的安全分析的协议，你能从中获益。

……顺利完工！

TLS RFC中还包含很多我们这里遗漏的 内容，它是一份可读性非常好的规范。我们覆盖的内容是对Firefox和Amazon之间的220毫秒的舞蹈进行观察所看到的一条路径。这个过程很大程度 上受Amazon在ServerHello消息中所选择的TLS_RSA_WITH_RC4_128_MD5密码套件的影响，这是一个合理的选择，因为它 对速度的倾向比对安全的倾向更多一点。

如我们所看到的，如果有人能将Amazon的模数“n”分解成“p”,“q”，那么他就可以有效解密所有的“安全”流通，直到Amazon换掉它的证书。所以Amazon通过每年替换一次证书的方式来平衡这方面的担心。

其中有一个密码套件是“TLS_DHE_RSA_WITH_AES_256_CBC_SHA”，它使用Diffie-Hellman密钥交换算法，这个算法具有良好的 “正向安全”的特点。也就意味这如果某人破解了密码交换的数学原理，对于解密下一个会话也没有什么益处。这个算法的缺点是需要计算更大的数字，所以对于一个很忙的服务器来说计算成本更大。“高级加密标准”（AES）出现在我们提供的很多密码套件中。它与RC4 的不同在于它一次加密16字节的“数据块”而不是一个字节，由于它的密钥可以大到256比特，所以很多人认为它比RC4要更安全。

仅需220毫秒中，网络中两个端点连接到一起，提供了足够资料来信任对方，建立加密算法，并开始进行加密的信息传输。

我写了一个程序对文章中所提及的握手协议走了一遍。

关于作者

Jeff 是一个软件开发工程师，他在http://www.moserware.com/上有一个自己的博客。

注意：这篇文章最初发表在Moserware上面，也就是Jeff Moser的博客里。

查看英文原文：The First Few Milliseconds of an HTTPS Connection。

不过我在家直接用笔记本搜索到的无线情况如下：在一共搜索到的7个无线节点中，有1个没有采用任何的加密措施，可以直接连接上。

而且路由器启用了DHCP，我毫不费力的得到了一个IP地址192.168.1.100，通过这个IP地址，那么默认的路由器ip就是192.168.1.1了。

TP-LINK的路由器，默认用户名、密码是admin/admin，别的品牌默认密码不外乎password、changeme（话说回来，这种人人皆知的也不好叫密码了），顺利进入。

看来这个路由器买回来唯一做过的就是按着配置指南，step by step的输入了ADSL的账号，可以打开路由器时自动连接。除此之外，就是一座不设防的空城。

通过上述“入侵”的过程，你也许对如何加强安全性有点头目了：

1. 隐藏SSID号
   SSID（Service Set Identifier）也可以写为ESSID，用来区分不同的网络，最多可以有32个字符，无线网卡设置了不同的SSID就可以进入不同网络，SSID通常由AP广播出来，通过XP自带的扫描功能可以相看当前区域内的SSID。出于安全考虑可以不广播SSID，此时用户就要手工设置SSID才能进入相应的网络。简单说，SSID就是一个无线局域网的名称，只有设置为名称相同SSID的值的电脑才能够连接到同一个无线网络中互相通信。
2. 设置非默认管理端口和复杂密码
   不要使用192.168.X.1的管理端口和admin、admin这样的密码
   别人都总结的好好的了 http://www.phpv.net/html/1553.html
3. 禁用DHCP
   别一下网段、网关什么的都暴露了
4. MAC地址过滤
   只允许自己的网卡访问路由，其它一概禁止

以上这些，只要您打开路由器的配置界面，从上到下，每一项都点一遍，就知道在哪里设置了。不过这些“雕虫小技”，除了最后一项会对入侵者设置一些障碍（可以通过伪造mac地址破解），其它的操作只防得了君子，对小人是一点用都没有的。要想把小人赶出门外，只能用加密措施。

安全类型选择WPA/WPA2，安全选项选择WPA2，加密方法选择AES，这三者是现在最安全的无线网络设置组合。

有了以上理论基础，网络嗅探工具加上暴力破解工具有了用武之地。按照下面几个帖子里的内容，平均10分钟就可以破解出使用WEP加密方法的密码。

BackTrack 使用全解

XP系统里利用VMware虚拟机启动BT3破解无线WEP和WPA傻瓜版教程

Intel3945ABG在BT3下破解有（无）客户端wep简明教程

WPA用Temporary Key Integrity Protocol (TKIP)机制避免了WEP的这个重大缺陷，一般支持WEP的无线网卡和路由都能支持WPA。当然更安全的是WPA2加密协议，使用AES来代替TKIP。至于WPA-PSK则是WPA Personal的缩写，一般家庭使用，而WPA Enterprise顾名思义适合企业用户使用。如果你的无线路由器或网卡不支持WPA2，那么试试升级firmware或者驱动，实在不行使用WPA，千万不要再使用WEP了。

参考文章 http://arstechnica.com/security/news/2008/04/wireless-security.ars

Related posts:

• 每个网民都该知道的安全知识
• WebSphere遗忘管理控制台密码怎么办？外一篇其它各种密码的补救措施
• 注册Weblogic9为Windows服务及外一篇
• 安全第一-WebSphere启用全局安全性
• IBM WebSphere Recent Supports

想不到霍炬在谈论高级编程之余还为广大网民考虑的如此周到，写了一篇《匿名网民的安全指南》，现在连载到第二部分，大家可以点击下面链接去看看。

        匿名网民的安全指南(1)           匿名网民的安全指南(2)

内容很入门，当然是对于我这样的IT从业人员来说， 一般人，特别是小姑娘看到估计还是会头大。不过像现在报纸、电台里一直宣传的反电话、短信诈骗一样，讲的多了大家自然也会慢慢注意，特别是对于“急需提高自己的安全级别的”人来说，应该会有帮助。

因为“6 本文会时常修补增加内容”，所以我就不转载了，不过这个系列的文章应该还没完，因为现在最重要的无线安全没有介绍到。既然如此，那我就贴上关于无线安全的文章。

       配置无线的方法 Geek to Live: Set up a home wireless network

       加固无线的方法  The ABCs of securing your wireless network

       否则的话，就等着 How to Crack a Wi-Fi Network’s WEP Password with BackTrack

       如果你认为无线密码被破了大不了让别人蹭蹭网，只要那小子不下BT也没啥关系，那你可要注意了你们已经在同一个局域网中，你的共享资源都在别人的眼皮底下，你的C盘、D盘、E盘过不了多久也会对别人开放，你发送的每一个网络包别人都可以截取。

当然避免的方法很多，如果你对霍炬的两篇文章看的云里雾里，那么最简单的就是下载个360安全卫士，做一下“安全体检”，这样本机的安全至少有了保证，但是在公共计算机上的安全主要靠安全意识了。如果你看不明白无线安全的那三篇文章（或者你懒得看英文），那么等俺有空了，会翻译一下。当然时间也许要个几天，因为我喜欢每步步骤都做一下，确认文章中的操作可行，才会发出来。

Related posts:

• 安全第一-WebSphere启用全局安全性
• 家庭无线网络简明安全指南
• WebSphere遗忘管理控制台密码怎么办？外一篇其它各种密码的补救措施
• 注册Weblogic9为Windows服务及外一篇
• IBM WebSphere Recent Supports