解决的核心问题是：你是谁？
http提供了一系列的技术和机器，可用来跟踪身份，进行安全性检测，控制对内容的访问。
客户端识别与cookie机制HTTP最初是一个匿名，无状态的请求/响应协议。服务器处理来自客户端的请求，然后向客户端回送一条响应。web服务器几乎没有什么信息可以用来判定是哪个用户发送的请求，也无法记录来访用户的请求序列。
用户识别机制
- 承载用户身份信息的HTTP首部
- 客户端IP地址跟踪，通过用户的IP地址对其进行识别
- 用户登录，用认证方式来识别用户
- 胖URL，一种在URL中嵌入识别信息的技术
- cookie，一种功能强大且高效的持久身份识别技术
HTTP首部
下表给出了7种常见的用来承载用户相关信息的HTTP请求首部。后面3个首部是扩展类型的请求首部。
为了使web站点的登录更加简便，HTTP中包含了一种内建机制，可以用WWW-Authenticate首部和Authorization首部向web站点传送用户的相关信息。一旦登录，浏览器就可以不断地在每条发往这个站点的请求中发送这个登录信息了。在HTTP中，基本认证是一种用来允许Web浏览器或其他客户端程序在请求时提供用户名和口令形式的身份凭证的一种登录验证方式。在发送之前是以用户名追加一个冒号然后串接上口令，并将得出的结果字符串再用Base64算法编码。例如，提供的用户名是Aladdin、口令是open sesame，则拼接后的结果就是Aladdin:open sesame，然后再将其用Base64编码，得到QWxhZGRpbjpvcGVuIHNlc2FtZQ==。最终将Base64编码的字符串发送出去，由接收者解码得到一个由冒号分隔的用户名和口令的字符串。虽然对用户名和口令的Base64算法编码结果很难用肉眼识别解码，但它仍可以极为轻松地被计算机所解码，就像其容易编码一样。编码这一步骤的目的并不是安全与隐私，而是为将用户名和口令中的不兼容的字符转换为均与HTTP协议兼容的字符集。
一个典型的HTTP客户端和HTTP服务器的对话，服务器安装在同一台计算机上（localhost），包含以下步骤：
- 客户端请求一个需要身份认证的页面，但是没有提供用户名和口令。这通常是用户在地址栏输入一个URL，或是打开了一个指向该页面的链接。
- 服务端响应一个401应答码，并提供一个认证域。
- 接到应答后，客户端显示该认证域（通常是所访问的计算机或系统的描述）给用户并提示输入用户名和口令。此时用户可以选择确定或取消。
- 用户输入了用户名和口令后，客户端软件会在原先的请求上增加认证消息头（值是base64encode(username+":"+password)），然后重新发送再次尝试。
- 在本例中，服务器接受了该认证屏幕并返回了页面。如果用户凭据非法或无效，服务器可能再次返回401应答码，客户端可以再次提示用户输入口令。
注意:客户端有可能不需要用户交互，在第一次请求中就发送认证消息头。
优点 基本上所有流行的网页浏览器都支持基本认证，在可信网络环境中使用基本认证。
缺点：保密性不强，不能跨站点，不同的站点需要重新输入账户密码；现存的浏览器保存认证信息直到标签页或浏览器被关闭，或者用户清除历史记录。[2]HTTP没有为服务器提供一种方法指示客户端丢弃这些被缓存的密钥。这意味着服务器端在用户不关闭浏览器的情况下，并没有一种有效的方法来让用户登出。
胖URL可以通过胖URL将服务器上若干个独立的HTTP事务捆绑成一个”会话”或”访问”。用户首次访问这个web站点时，会生成一个唯一的ID，用服务器可以识别的方式将这个ID添加到URL中，然后服务器就会将客户端重新导向这个胖URL。
问题：
- 丑陋的URL
- 无法共享URL
- 破坏缓存
- 额外的服务器负荷
- 逃逸口
- 在会话间是非持久的
cookie是当前识别用户，实现持久会话的最好方式。最初由网景公司开发，但现在所有的主要浏览器都支持他。
Cookie通常也叫做网站cookie,浏览器cookie或者http cookie,是保存在用户浏览器端的，并在发出http请求时会默认携带的一段文本片段。它可以用来做用户认证，服务器校验等通过文本数据可以处理的问题。
常见用途
- 会话管理
- 记录用户的登录状态是cookie最常用的用途。通常web服务器会在用户登录成功后下发一个签名来标记session的有效性，这样免去了用户多次认证和登录网站。
- 记录用户的访问状态，例如导航啊，用户的注册流程啊。
-
个性化信息
- Cookie也经常用来记忆用户相关的信息，以方便用户在使用和自己相关的站点服务。例如：ptlogin会记忆上一次登录的用户的QQ号码，这样在下次登录的时候会默认填写好这个QQ号码。
- Cookie也被用来记忆用户自定义的一些功能。用户在设置自定义特征的时候，仅仅是保存在用户的浏览器中，在下一次访问的时候服务器会根据用户本地的cookie来表现用户的设置。例如google将搜索设置（使用语言、每页的条数，以及打开搜索结果的方式等等）保存在一个COOKIE里。
- 记录用户的行为
- 最典型的是公司的TCSS系统。它使用Cookie来记录用户的点击流和某个产品或商业行为的操作率和流失率。当然功能可以通过IP或http header中的referrer实现，但是Cookie更精准一些。
电商和QQ登录的例子
因为HTTP协议是无状态的，即服务器不知道用户上一次做了什么，这严重阻碍了交互式Web应用程序的实现。在典型的网上购物场景中，用户浏览了几个页面，买了一盒饼干和两瓶饮料。最后结帐时，由于HTTP的无状态性，不通过额外的手段，服务器并不知道用户到底买了什么。 所以Cookie就是用来绕开HTTP的无状态性的“额外手段”之一。服务器可以设置或读取Cookies中包含信息，借此维护用户跟服务器会话中的状态。
- 在刚才的购物场景中，当用户选购了第一项商品，服务器在向用户发送网页的同时，还发送了一段Cookie，记录着那项商品的信息。当用户访问另一个页面，浏览器会把Cookie发送给服务器，于是服务器知道他之前选购了什么。用户继续选购饮料，服务器就在原来那段Cookie里追加新的商品信息。结帐时，服务器读取发送来的Cookie就行了。
- Cookie另一个典型的应用是当登录一个网站时，网站往往会请求用户输入用户名和密码，并且用户可以勾选“下次自动登录”。如果勾选了，那么下次访问同一网站时，用户会发现没输入用户名和密码就已经登录了。这正是因为前一次登录时，服务器发送了包含登录凭据（用户名加密码的某种加密形式）的Cookie到用户的硬盘上。第二次登录时，（如果该Cookie尚未到期）浏览器会发送该Cookie，服务器验证凭据，于是不必输入用户名和密码就让用户登录了。
cookie的类型
-
Session Cookie：
这个类型的cookie只在会话期间内有效，即当关闭浏览器的时候，它会被浏览器删除。设置session cookie的办法是：在创建cookie不设置Expires即可。 -
Persistent Cookie
持久型cookie顾名思义就是会长期在用户会话中生效。当你设置cookie的属性Max-Age为1个月的话，那么在这个月里每个相关URL的http请求中都会带有这个cookie。所以它可以记录很多用户初始化或自定义化的信息，比如什么时候第一次登录及弱登录态等。 -
Secure cookie
安全cookie是在https访问下的cookie形态，以确保cookie在从客户端传递到Server的过程中始终加密的。这样做大大的降低的cookie内容直接暴露在黑客面前及被盗取的概率。 -
HttpOnly Cookie
目前主流的浏览器已经都支持了httponly cookie。1.IE5+ 2.Firefox 1.0+ 3.Opera 8.0+ 4.Safari/Chrome。在支持httponly的浏览器上，设置成httponly的cookie只能在http(https)请求上传递。也就是说httponly cookie对客户端脚本语言(javascript)无效，从而避免了跨站攻击时JS偷取cookie的情况。当你使用javascript在设置同样名字的cookie时，只有原来的httponly值会传送到服务器。 -
3rd-party cookie
第一方cookie是cookie种植在浏览器地址栏的域名或子域名下的。第三方cookie则是种植在不同于浏览器地址栏的域名下。例如：用户访问a.com时，在ad.google.com设置了个cookie，在访问b.com的时候，也在ad.google.com设置了一个cookie。这种场景经常出现在google adsense，阿里妈妈之类的广告服务商。广告商就可以采集用户的一些习惯和访问历史。 -
Super Cookie
超级cookie是设置公共域名前缀上的cookie。通常a.b.com的cookie可以设置在a.b.com和b.com，而不允许设置在.com上，但是很不幸的是历史上一些老版本的浏览器因为对新增后缀过滤不足导致过超级cookie的产生。 - Zombie Cookie
僵尸cookie是指那些删不掉的，删掉会自动重建的cookie。僵尸cookie是依赖于其他的本地存储方法，例如flash的share object,html5的local storages等，当用户删除cookie后，自动从其他本地存储里读取出cookie的备份，并重新种植。
如果简单点划分的话：可以笼统的分为:会话cookie和持久cookie。会话cookie和持久cookie的唯一区别就是他们的过期时间。 如果设置了Discard参数，或者没有设置Expires或Max-Age参数来说明扩展的过期时间，这个cookie就是一个会话cookie。
不同的站点使用不同的cookie
cookie的域属性
产生cookie的服务器可以向Set-Cookie响应首部添加一个Domain属性来控制哪些站点开业看到那个cookie。
Set-cookie: user="wilson";domain="wilsonliu.cn"
则用户访问的任何以wilsonliu.cn结尾的站点都会讲此cookie发布出去。
cookie的路径属性
cookie规范甚至允许用户将cookie与部分web站点关联起来。可以通过Path属性来实现这一功能。
Set-cookie: year="21";domain="wilsonliu.cn";path=/year/
则只会在/year/下的站点时才会发布此cookie。
Cookie的实现
Cookie是web server下发给浏览器的任意的一段文本，在后续的http 请求中，浏览器会将cookie带回给Web Server。同时在浏览器允许脚本执行的情况下，Cookie是可以被JavaScript等脚本设置的。
http方式:以访问http://movie.weibo.com为例
- Step1.客户端发起http请求到Server
GET /index.php HTTP/1.1
Host: http://movie.weibo.com(这里是省去了User-Agent,Accept等字段)
- Step2. 服务器返回http response,其中可以包含Cookie设置
HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: name=value
Set-Cookie: name2=value2; Expires=xxxx
(content of page)- Step3. 后续访问http://movie.weibo.com的相关页面
GET /spec.html HTTP/1.1
Host: www.webryan.net
Cookie: name=value; name2=value2
Accept: */*需要修改cookie的值的话，只需要Set-Cookie: name=newvalue即可，浏览器会用新的值将旧的替换掉。
cookie成分
cookie版本0 (Netscape)
Set-Cookie首部
- Name=Value
- Expires
- domain
- Path
- Secure
cookie首部
客户端发送请求时，会将所有与域，路径，安全过滤器匹配的未过期的cookie都发送给这个站点。
cookie版本1 (RFC 2965)
Set-Cookie2
- Name = Value
- Version
- Comment
- CommentURL
- Discard
- domain
- Max-Age
- Path
- Port
- Secure
cookie首部
版本1的cookie会带回与传输的每个cookie相关的附加信息，用来描述每个cookie途径的过滤器。每个匹配的cookie都必须包含来自相应的Set-Cookie2首部的所有Domain,Port和Path属性。
基本认证机制基本认证质询首部
HTTP/1.0 401 Unauthorized
WWW-Authenticate: Basic realm=quoted-realm响应首部(通过base64编码传输)
Authorization:Basic base64-username-and-password定义
摘要访问认证是一种协议规定的Web服务器用来同网页浏览器进行认证信息协商的方法。它在密码发出前，先对其应用哈希函数，这相对于HTTP基本认证发送明文而言，更安全。
从技术上讲，摘要认证是使用随机数来阻止进行密码分析的MD5加密哈希函数应用。它使用HTTP协议。
基本认证便捷灵活，但极不安全。用户名与密码明文传输，也没有采取任何措施防止对报文的篡改。安全使用基本认证的唯一方式就是将其与SSL配合使用。
摘要认证与基本认证兼容。但却更为安全。
摘要认证的改进
- 永远不会以明文的方式在网络上发送密码
- 可以防止恶意用户捕获并重放认证的握手过程
- 可以有选择地防止对报文内容的篡改
- 防范其他几种常见的攻击方式
- 用摘要保护密码
摘要认证遵循的箴言是”绝不通过网络发送密码”。客户端不会发送密码，而是会发送一个“指纹”或密码的”摘要”，这是密码的不可逆扰码。
单向摘要
在 HTTP 摘要认证中使用 MD5 加密是为了达成"不可逆的"，也就是说，当输出已知的时候，确定原始的输入应该是相当困难的。
摘要是”对信息主体的浓缩”。摘要是一种单向函数，主要用于将无限的输入值转换为有限的浓缩输出值。常见的摘要函数MD5，会将任意长度的字节序列转换为一个128位的摘要。
有时也将摘要函数称为加密的校验和，单向散列函数或指纹函数。
用随机数防止重放攻击
使用单向摘要就无需以明文形式发送密码，没有哪个而已用户能够轻易地从摘要中解码出原始密码。
但是仅仅隐藏密码并不能避免危险，因为即便不知道密码，也可以截获摘要，并重放给服务器。摘要和密码一样好用。
为防止此类重放攻击的发生服务器可以向客户端发送一个称为随机数(nonce)的特殊令牌，这个数会经常发生变化(可能是每毫秒，或者是每次认证都变化)。客户端在计算摘要之前要先将这个随机数令牌附加到密码上去。
摘要的计算
摘要认证的核心就是对公共信息，保密信息和有时限的随机值这个组合的单项摘要。
数据
与安全性相关的数据(A1) ——包含有用户名，密码，保护域和随机数等内容
与报文有关的数据(A2) ——比如URL，请求方法和报文实体，A2有助于防止方法，资源或报文被篡改
预授权
在普通的认证方式中，事务结束之前，每条请求都要有一次请求/质询的循环。
如果客户端事先知道下一个随机数是什么，就可以取消这个请求/质询循环。
- 服务器预先在Authentication-Info成功首部中发送下一个随机数
- 服务器允许在一小段时间内使用同一个随机数
- 客户端和服务器使用同步的，可预测的随机数生成算法
应该考虑的实际问题
- 多重质询
- 差错处理
- 保护空间
- 重写URI
- 缓存
安全性考虑
- 首部篡改
- 重放攻击
- 多重认证机制
- 词典攻击
- 恶意代理攻击和中间人攻击
- 选择明文攻击
- 存储密码
定义:
超文本传输安全协议（英语：Hypertext Transfer Protocol Secure，缩写：HTTPS，常称为HTTP over TLS，HTTP over SSL或HTTP Secure）是一种通过计算机网络进行安全通信的传输协议。HTTPS经由HTTP进行通信，但利用SSL/TLS来加密数据包。HTTPS开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。这个协议由网景公司（Netscape）在1994年首次提出，随后扩展到互联网上。
历史上，HTTPS连接经常用于万维网上的交易支付和企业信息系统中敏感信息的传输。在2000年代晚期和2010年代早期，HTTPS开始广泛使用于保护所有类型网站上的网页真实性，保护账户和保持用户通信，身份和网络浏览的私密性。
HTTPS是最流行的HTTP安全形式，它是由网景公司首创，所有主要的浏览器和服务器都支持此协议。
使用HTTPS时，所有的HTTP请求和响应数据在发送到网络之前，都要进行加密。HTTPS在HTTP下面提供了一个传输级的密码安全层——可以使用SSL，也可以使用其后继者，传输层安全(Transport Layer Security,TLS)。
大部分困难的编码及解码工作都是在SSL库中完成的，所以web客户端和服务器在使用安全HTTP时无需过多地修改器协议处理逻辑。在大多数情况下，只需要用SSL的输入/输出调用取代TCP的调用，再增加其他几个调用来配置和管理安全信息就行了。
一个到某网站的HTTPS连接可被信任的充分必要条件：
HTTPS的主要思想是在不安全的网络上创建一安全信道，并可在使用适当的加密包和服务器证书可被验证且可被信任时，对窃听和中间人攻击提供合理的防护。
HTTPS的信任继承基于预先安装在浏览器中的证书颁发机构（如Symantec、Comodo、GoDaddy和GlobalSign等）（意即“我信任证书颁发机构告诉我应该信任的”）。因此，一个到某网站的HTTPS连接可被信任，当且仅当：
- 用户相信他们的浏览器正确实现了HTTPS且安装了正确的证书颁发机构；
- 用户相信证书颁发机构仅信任合法的网站；
- 被访问的网站提供了一个有效的证书，意即，它是由一个被信任的证书颁发机构签发的（大部分浏览器会对无效的证书发出警告）；
- 该证书正确地验证了被访问的网站（如，访问https://example.com 时收到了给example.com而不是其它组织的证书）；
- 或者互联网上相关的节点是值得信任的，或者用户相信本协议的加密层（TLS或SSL）不能被窃听者破坏。
与HTTP的差异
- 与HTTP的URL由“http://”起始且默认使用端口80不同，HTTPS的URL由“https://”起始且默认使用端口443。
- HTTP是不安全的，且攻击者通过监听和中间人攻击等手段，可以获取网站帐户和敏感信息等。HTTPS被设计为可防止前述攻击，并在正确配置时被认为是安全的。
协议层
HTTP协议和安全协议同属于应用层（OSI模型的最高层），具体来讲，安全协议工作在HTTP之下，运输层之上：安全协议向运行HTTP的进程提供一个类似于TCP的套接字，供进程向其中注入报文，安全协议将报文加密并注入运输层套接字；或是从运输层获取加密报文，解密后交给对应的进程。严格地讲，HTTPS并不是一个单独的协议，而是对工作在一加密连接（TLS或SSL）上的常规HTTP协议的称呼。
服务器设置
要使一网络服务器准备好接受HTTPS连接，管理员必须创建一数字证书，并交由证书颁发机构签名以使浏览器接受。证书颁发机构会验证数字证书持有人和其声明的为同一人。浏览器通常都预装了证书颁发机构的证书，所以他们可以验证该签名。
作为访问控制
HTTPS也可被用作客户端认证手段来将一些信息限制给合法的用户。要做到这样，管理员通常会给每个用户创建证书（通常包含了用户的名字和电子邮件地址）。这个证书会被放置在浏览器中，并在每次连接到服务器时由服务器检查。
保护HTTP的安全
- 服务器认证
- 客户端认证
- 完整性
- 加密
- 效率
- 普适性
- 管理的可扩展性
- 适应性
- 在社会的可行性
数字加密
- 密码 对文本进行编码，使偷窥者无法识别的算法
- 密钥 改变密码行为的数字化参数
- 对称密钥加密系统 编/解码使用相同密钥的算法
- 不对称密钥加密系统 编/解码使用不同密钥的算法
- 公开密钥加密系统 一种能够使数百万计算机便捷地发送机密报文的系统
- 数字签名 用来验证报文未被伪造或篡改的校验和
- 数字证书 由一个可信的组织验证和签发的识别信息
密码
密码学基于一种名为密码(cipher)的秘密代码。密码是一套编码方案——一种特殊的报文编码方式和一种稍后使用的相应解码方式的结合体。加密之前的原始报文通常被称为明文(plaintext或cleartext)。使用了密码之后的编码报文通常被称作密文(ciphertext)。
使用密钥的密码
编码算法和编码机器都可能落入敌人手中，所以大部分机器上都有一些盘号，可以将其设置为大量不同的值以改变密码的工作方式。这些密码参数被称为密钥(key)，要在密码机中输入正确的密钥，解密过程才能正确进行。
对称密钥加密技术
编码时使用的密钥值和解码时一样，这就是对称密钥(symmetric-key)。
保持密钥的机密状态是很重要的，在很多情况下，编/解码算法都是众所周知的，因此密钥就是唯一保密的东西了。好的加密算法会迫使攻击者试遍每一个可能的密钥，才能破解代码。用暴力去尝试所有的密钥值称为枚举攻击(enumeration attack)。可用密钥的数量取决于密钥中的位数，以及可能的密钥中有多少是有效的。
对称密钥加密技术的缺点之一就是发送者和接受者在互相对话之前，一定要有一个共享的保密密钥。每对通信实体都需要自己的私有密钥。如果有N个节点，每个节点都要和其他所有的N-1个节点进行安全对话，总共需要N的平方个保密密钥，这将是一个管理噩梦。
公开密钥加密技术
公开密钥使用了2个非对称密钥:一个用来对主机报文编码，另外一个用来对主机报文解码。编码密钥是众所周知的，但只要主机才知道私有的解密密钥。
所有的公开密钥非对称加密系统所面临的共同挑战是，要确保即便有人拥有了下面所有的线索，也无法计算出保密的私有密钥:
- 公开密钥
- 一小片拦截下来的密文(可通过对网络的嗅探获取)
- 一条报文及与之相关的密文(对任意一段文本运行加密器就可以得到)
混合加密系统和会话密钥
两节点间通过便捷的公开密钥加密技术建立起安全通信，然后再用那条安全的通道产生并发送临时的随即对称密钥，通过更快的对称加密技术对其余的数据进行加密。
数字签名
除了加/解密报文之外，还可以用加密系统对报文进行签名(sign)，以说明是谁编写的报文，同时证明报文未被篡改过。这种技术被称为数字签名(digital signing)。
客户端将变长报文提取为定长的摘要
客户端对摘要应用了一个”签名”函数，这个函数会将用户的私有密钥作为参数。因为只有用户才知道私有密钥，所以正确的签名函数会说明签名者就是其所有者。
一旦计算出签名，客户端就将其附加在报文的末尾，并将报文和签名都发送给对方。
在接收端，会用公开密钥对签名进行检查，如果不匹配则表示已被篡改。
使用数字签名的好处
- 签名可以验证是作者编写了这条报文，只有作者才会有最机密的私有密钥，因此，只有作者才能计算出这些校验和。校验和就像来自作者的个人“签名”一样。
- 签名可以防止报文被篡改，如果有恶意攻击者在报文传输过程中对其进行了修改，校验和就不再匹配了。由于校验和只有作者保密的私有密钥才能产生，所以攻击者无法为篡改了的报文伪造出正确的校验码。
数字证书
数字证书中包含了由某个受信任组织担保的用户或公司的相关信息。数字证书都是由官方的”证书颁发机构”以数字方式签发的。
通过HTTPS建立了一个安全web事务之后，现代浏览器都会自动获取所连接服务器的数字证书。如果服务器没有证书，安全连接就会失败。浏览器收到证书的时候会对签名颁发机构进行检查。
HTTPS——细节介绍
HTTPS将HTTP协议与一组强大的对称，非对称和基于证书的加密技术结合在一起，使得HTTPS不仅很安全，而且很灵活，很容易在处于无序状态的，分散的全球互联网上进行管理。
客户端会对web资源执行某事务时，他会去检查URL的方案，如果URL的方案是https，客户端就会打开一条到服务器端口443(而不是传统的http默认的80端口)的连接，然后与服务器进行SSL”握手”，以二进制格式与服务器交换一些SSL安全参数，附加上加密的HTTP命令。
站点证书的有效性
- 日期检测
- 签名颁发者可信度检测
- 签名检测
- 站点身份检测
通过代理以隧道形式传输安全流量
客户端通常会用web代理服务器代表它们来访问web服务器。但只要客户端开始用服务器的公开密钥对发往服务器的数据进行加密，代理就再也不能读取HTTP首部了！就无法知道应该将请求转向何处了。
为了使HTTPS与代理配合工作，可以用HTTPS SSL隧道协议。使用HTTPS隧道协议，客户端首先告诉代理，它想要连接的安全主机和端口。这是在开始加密之前，以明文形式告知的。
https 知识参考
原文请访问：http://fanqieto.top/2017/09/23/%E5%85%A8%E9%9D%A2%E8%A7%A3%E8%AF%BBhttp/