MsSQL使用加密连接SSL/TLS

说明

应用程序通过未加密的通道与数据库服务器通信,
这可能会造成重大的安全风险。在这种情况下, 攻击者可以修改用户输入的数据,
甚至对数据库服务器执行任意 SQL 命令。

例如,当您使用以下连接字符串时,就可能存在这种风险:

<connectionStrings>  
<add name="Test" connectionString="Data Source=210.10.20.10,1433; Initial Catalog=myDataBase;User ID=myUsername;Password=myPassword;" providerName="System.Data.SqlClient" /> 
</connectionStrings>

 

!!!
!!! 你们这些旱鸭子比我想象得要厉害多了,看来我要认真一些了 !!!

图片 1

重拳先生

概述


TLS是现在广泛使用的安全协议,全名为传输层安全协议(Transport Layer
Security).它的前身是SSL,即安全套接层(Secure Socket Layer).

网景公司(Netscape)在1994年推出首版网页浏览器,网景导航者时,推出HTTPS协议,以SSL进行加密,这是SSL的起源。

后来,Google在04年发布 在SSL
3.0中发现设计缺陷,建议禁用此一协议。攻击者可以向TLS发送虚假错误提示,然后将安全连接强行降级到过时且不安全的SSL
3.0,然后就可以利用其中的设计漏洞窃取敏感信息。最后各大公司都选择了强制使用TLS.

目前SSL/TLS已成为互联网上保密通讯的工业标准

更新: 这个SSL/TLS就像是在应用层和传输层中间多加的半层. 其实就是库嘛,
应用程序可以选择性的进行调用. 以Web服务为例, 如果没有调用的话就是http,
如果调用了的话就是https了.反正提供了API.
二者虽然只有一个字的差距但是却又很大的不同的. 一个是文本格式的,
一个是二进制的格式的.

尽管他自己是半个层, 但是其内部也是分了很多层的(进行了分层设计),
简单的说一下:

  1. 最底层: 基础算法原语的实现, aes, rsa, md5
  2. 向上一层: 各种算法的实现
  3. 再向上一层: 组合算法实现的半成品
  4. 用各种组件拼装而成的种种成品密码学协议/软件:
    1. tls, ssh, …

启用SSL/TLS加密连接

大部分数据库服务器都提供支持使用SSL/TLS来加密传输所有数据,您应当尽可能的使用它。在您的连接字符串上加上Encrypt=True即可。如果您的开发环境没有可信证书,加上TrustServerCertificate=True来取消验证证书是否受信。

<connectionStrings>  
<add name="Test" connectionString="Data Source=210.10.20.10,1433; Initial Catalog=myDataBase;User ID=myUsername;Password=myPassword;Encrypt=True;" providerName="System.Data.SqlClient" /> 
</connectionStrings>

 

相关链接:

原文链接:

现在来聊聊服务器的加密,这文章会覆盖整个 Node.js
加密的前因后果,所以会比较长,内容分为:

正片开始


提到了TLS,就一定要说一下HTTPS了,一般对HTTPS的定义是HTTP over SSL/HTTP over TLS/HTTP over Secure.

而提到了HTTPS,有不得不说一下浏览器了.那么我来慢慢按照顺序来说一下.

首先,HTTPS借由HTTP(如果对HTTP不熟悉可以考虑看一下隔壁的HTTP阅读笔记)来传输信息,但为了某些需要,要加密某些信息,此时它就借助了SSL/TLS来加密传输的数据包.一般的,HTTPS的默认使用端口为443.

最重要的部分就是协议实现的方式了.
下面来说下:(可以结合下面的图来看,超清版的.SVG)


首先客户端向Web服务器发送一个HTTPS请求,该请求包含了客户端的条件以及一个随机数.关键字:{
本地条件 }

  • 具体内容包括:支持的协议版本,比如TLS1.0版,一个客户端生成的随机数(稍后用于生成“会话密钥”),支持的加密算法(如RSA公钥加密)和支持的压缩算法。

此时,客户端的随机数被Server端获得.

然后收到一个Server回应消息,这个回应中确定了双方在后来要使用的各种连接参数.关键字:{
确定参数 }

  • 这次的回应包括:确认使用的加密通信协议版本,比如TLS
    1.2版本(如果浏览器与服务器支持的版本不一致,服务器关闭加密通信),一个服务器生成的随机数(稍后用于生成“对话密钥”),确认使用的加密方法(如RSA公钥加密),服务器证书。

此时,双方手中都有了双方的随机数.
至此,Phase 1结束.

  • { Phase1中交换了随机数,确定了连接参数 }

再然后当双方知道了连接参数,客户端与服务器交换证书(依靠被选择的公钥系统)(Phase2-Phase3)

服务器端向客户端发送自己的证书和公钥并要求客户端提供证书.
看到这里,想必会有这样的疑问:客户端哪里来的证书?

我认为,本机的电子证书是通过浏览器中预设的CA来获取的.

SSL 服务器证书提供加密和安全功能。
客户端证书提供用户身份验证功能。
客户端证书由证书颁发机构颁发给用户。

客户端这边,通过CA的公钥解密服务器端的证书,还会检测是否被吊销,
确认是否有效.

  • 所以说,这里的证书是经过了认证中心的私钥加密的

关键字:{ 确认服务器端身份 }

此时,客户端手中多了服务器端的公钥.
至此,Phase2结束.

  • {Phase2中客户端验证了服务器的身份}

接着根据之前的请求,客户端向服务器端发送自己的证书和自己的公钥.

客户端有证书即双向身份认证,没证书时随机生成公钥。

服务器端对客户端发来的证书进行检查,如果有问题会直接中断私密通信.

然后,客户端再次生成一个随机数,注意,此时生成的随机数是经过了服务器端公钥的加密的,接着将其发送到了服务器端.

当服务器端收到了这个随机数,(我们把他叫做pre-master-secret),双方会根据之前商定的加密方法,对之前的两个随机数加上这个PMS,生成一个会话密钥(MS).

此时,服务器端手中自己的公钥和私钥,以及MS
客户端手中有自己的公钥和私钥,以及MS
至此,Phase3结束.

  • {Phase3中双方得到了会话密钥}

最后,双方关键数据的加密传输均使用这个“会话密钥”–主密钥

结束SSL握手.

至此,全部的SSL握手结束.

图片 2

SSL

  • <a>从 OpenSSL 开始</a>
  • <a>TLS HTTPS 服务器</a>
  • <a>Crypto 加密解密</a>

SSL/TLS的延时问题


既然HTTPS的数据传递是相对安全的,那为什么不给每一个域名都配上HTTPS呢?

原因很简单,延时,因为复杂的握手机制,会使得访问时间延长很多,那么到底有多少呢?

首先,HTTPS是建立在HTTP的,HTTP又是建立在TCP/IP上的,因此必定存在三次握手.

所以,我们可以得到:

HTTP耗时 = TCP握手
HTTPs耗时 = TCP握手 + SSL握手

我们可以做一个小测试:

命令行工具curl有一个w参数,可以用来测量TCP握手和SSL握手的具体耗时,以访问支付宝为例。

$ curl -w "TCP handshake: %{time_connect}, SSL handshake: %{time_appconnect}n" -so /dev/null https://www.alipay.com

我测试的一些结果样本供参考:

TCP handshake: 0.053, SSL handshake: 0.129
TCP handshake: 0.079, SSL handshake: 0.187
TCP handshake: 0.075, SSL handshake: 0.145
TCP handshake: 0.077, SSL handshake: 0.150

从结果可以看到,SSL握手的耗时大概是TCP握手的二-三倍。

也就是说,在建立连接的阶段,HTTPs链接比HTTP链接要长2-3倍的时间,当然了,具体数字取决于CPU的快慢和网络状况。

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

*
*
Website