PHP开发人员需要了解有关https /安全套接字层连接的信息？

当涉及到https连接的方式和原因时,我几乎一无所知.显然,当我传输密码或信用卡信息等安全数据时,https是一个重要的工具.但是我需要知道什么呢？您看到开发人员在项目中实施错误时最常见的错误是什么？是否有时候https只是一个坏主意？谢谢!

为站点提供HTTPS或安全套接字层(SSL)证书,通常由证书颁发机构(CA)签名,证书颁发机构(CA)实际上是受信任的第三方,用于验证有关您站点的一些基本详细信息,并对其进行认证以供使用在浏览器中.如果您的浏览器信任CA,则它信任该CA签署的任何证书(这称为信任链).

每个HTTP(或HTTPS)请求由两部分组成:请求和响应.当您通过HTTPS请求某些内容时,实际上在后台发生了一些事情:

客户端(浏览器)执行"握手",它请求服务器的公钥和标识.

此时,浏览器可以检查有效性(站点名称是否匹配？是日期范围当前？它是否由它信任的CA签名？).它甚至可以联系CA并确保证书有效.

客户端创建一个新的预主密钥,使用服务器的公钥加密(因此只有服务器可以对其进行解密)并发送到服务器

服务器和客户端都使用此预主密钥生成主密钥,然后用于为实际数据交换创建对称会话密钥

双方都发出信息说他们已经完成了握手

然后,服务器正常处理请求,然后使用会话密钥加密响应

如果连接保持打开,则每个都使用相同的对称密钥.

如果建立了新连接,并且双方仍然具有主密钥,则可以在"缩略握手"中生成新的会话密钥.通常,浏览器将存储主密钥,直到它关闭,而服务器将存储它几分钟或几个小时(取决于配置).

有关会话长度的更多信息,请参阅HTTPS对称密钥持续多长时间？

证书和主机名

为证书分配一个公用名(CN),对于HTTPS,它是域名.CN必须完全匹配,例如,具有"example.com"CN的证书将不匹配域"www.example.com",并且用户将在其浏览器中收到警告.

在SNI之前,无法在一个IP上托管多个域名.因为在客户端甚至发送实际的HTTP请求之前获取证书,并且HTTP请求包含告诉服务器使用什么URL的Host:标题行,所以服务器无法知道为给定的服务器提供什么样的证书请求.SNI将主机名添加到部分TLS握手中,因此只要它在客户端和服务器上都受支持(并且在2015年,它得到广泛支持),服务器就可以选择正确的证书.

即使没有SNI,服务多个主机名的一种方法是使用包含主题备用名称(SAN)的证书,这些证书本质上是证书有效的其他域.例如,谷歌使用单一证书来保护其中的许多网站.

另一种方法是使用通配符证书.可以获得像" .example.com"这样的证书,在这种情况下,"www.example.com"和"foo.example.com"都对该证书有效.但请注意,"example.com"与" .example.com" 不匹配,"foo.bar.example.com" 也不匹配.如果您使用"www.example.com"作为证书,则应将"example.com"上的任何人重定向到"www".现场.如果他们请求https://example.com,除非您将其托管在单独的IP上并拥有两个证书,否则将收到证书错误.

当然,您可以混合使用通配符和SAN(只要您的CA允许您这样做)并获得"example.com"和SAN" .example.com","example.net"和"例如.example.net".

形式

严格来说,如果您要提交表单,只要提交URL转到https:// URL,表单页面本身是否未加密就没关系.实际上,用户已被训练(至少在理论上)不提交页面,除非他们看到小的"锁定图标",所以即使表单本身也应该通过HTTPS提供来实现.

流量和服务器负载

HTTPS流量远远大于其等效的HTTP流量(由于加密和证书开销),并且还会给服务器带来更大的压力(加密和解密).如果您的服务器负载很重,那么可能需要非常谨慎地选择使用HTTPS提供的内容.

最佳实践

如果您不只是为整个网站使用HTTPS,它应该根据需要自动重定向到HTTPS.每当用户登录时,他们应该使用HTTPS,如果您正在使用会话cookie,则cookie应该设置安全标志.这可以防止截取会话cookie,这对于开放(未加密)的wifi网络的普及尤其重要.

页面上的任何资源都应来自用于页面的相同方案.如果在使用HTTPS加载页面时尝试从http://获取图像,则用户将收到安全警告.您应该使用完全限定的URL,或者另一种简单的方法是使用不包含主机名的绝对URL(例如,src ="/ images/foo.png"),因为它们适用于两者.

这包括外部资源(例如Google Analytics)

从HTTPS更改为HTTP时,请勿执行POST(表单提交).大多数浏览器会将此标记为安全警告.

我不打算深入研究SSL,gregmac做得很好,见下文;-).

但是,关于使用SSL/TLS的一些最常见(和关键)错误(不是特定的PHP):

应该强制执行HTTPS时允许HTTP

从HTTPS页面通过HTTP检索一些资源(例如图像,IFRAME等)

无意中从HTTPS页面指向HTTP页面 - 请注意,这包括"假"页面,例如"about:blank"(我已经看到这用作IFRAME占位符),这将不必要地和令人不快地弹出一个警告.

Web服务器配置为支持旧的,不安全的SSL版本(例如,SSL v2很常见,但可怕的很糟糕)(好吧,这不完全是程序员的问题,但有时候没有其他人会处理它......)

配置为支持不安全的密码套件的Web服务器(我见过只使用NULL密码,基本上提供绝对无加密)(同上)

自签名证书 - 阻止用户验证站点的身份.

即使提交到HTTPS页面,也要从HTTP页面请求用户的凭据.同样,这可以防止用户在提供密码之前验证服务器的身份......即使密码是加密传输的,用户也无法知道他是否在虚假网站上 - 或者即使它将被加密.

非安全cookie - 与安全相关的cookie(例如sessionId,身份验证令牌,访问令牌等)必须使用"secure"属性集进行设置.这个很重要!如果它没有设置为安全,安全cookie,例如SessionId,可以通过HTTP(!)传输 - 攻击者可以确保这种情况发生 - 从而允许会话劫持等等.当你在它时(这不是直接的)相关的),也在你的cookie上设置HttpOnly属性(有助于缓解一些XSS).

过度宽松的证书 - 假设您有多个子域,但并非所有子域都处于相同的信任级别.例如,您有www.yourdomain.com,dowload.yourdomain.com和publicaccess.yourdomain.com.因此,您可能会考虑使用通配符证书....但您也有secure.yourdomain.com或finance.yourdomain.com - 即使在不同的服务器上也是如此.然后,publicaccess.yourdomain.com将能够冒充secure.yourdomain.com ....虽然可能存在这样的情况,但通常你会想要一些特权分离......

这就是我现在所能记住的,可能会在以后重新编辑它...

至于何时使用SSL/TLS是一个不好的想法 - 如果您的公共信息不是针对特定受众(单个用户或注册成员),并且您并不特别关注他们从正确的来源(例如股票代码值必须来自经过验证的来源......) - 然后没有真正的理由产生开销(而不仅仅是性能...... dev/test/cert/etc).

但是,如果您的站点与另一个更敏感的站点之间共享资源(例如,相同的服务器),则更敏感的站点应该在此处设置规则.

此外,密码(和其他凭据),信用卡信息等应始终通过SSL/TLS.