码迷,mamicode.com
首页 > 其他好文 > 详细

互联网服务器的实现过程需要考虑哪些安全问题 & 加解密及哈希知识点

时间:2017-01-22 21:22:25      阅读:233      评论:0      收藏:0      [点我收藏+]

标签:glib   targe   关闭   改变   实现   hostname   byte   环境   art   

http://www.cnblogs.com/charlesblc/p/6341265.html 其中的一篇。

参考

https://zhuanlan.zhihu.com/p/20336461?refer=auxten

 

网络编程(四):互联网中TCP Socket服务器的实现过程需要考虑哪些安全问题?

在Internet环境下,安全问题我主要分为如下几类:

  1. 信息传输过程中被黑客窃取
  2. 服务器自身的安全
  3. 服务端数据的安全

 

首先,如果能用https,就尽量用https,能用nginx等常见服务器,就用常见服务器,主要能避免以下问题:

  • 自己实现的协议&Server端可能会有各种Bug,被缓冲区溢出攻击等
  • SSL加密体系在防监听方面已经足够成熟,值得信赖

 

如果需要自己实现Server端,实现一套合格的SSL还是很考验功底的:

  • 首先要弄明白SSL加密体系密钥交换的原理
  • 对各种对称、非对称加密算法要有深刻的理解
  • 用非对称加密算法怎么实现一套密钥交换体系
  • 如何处理ca证书,在自签名情况下怎么避免中间人攻击

工程实现过程中,要考虑:

  • 各种可能的缓冲区溢出攻击
  • SYN flood攻击,慢连接攻击
  • DDoS防起来有难度,但至少能防御DoS攻击

业务逻辑层面,要考虑:

  • 每个接口都要做好用户&权限验证
  • 接口会不会被人乱用,重放攻击
  • 攻击方会不会找到一个比较消耗服务端资源的接口,用很小的代价耗尽服务端资源
  • 用户的用户名密码会不会被通过接口破解,参见:2014 celebrity photo hack
  • 你的服务会不会被黑客利用去攻击别的服务,特别是会根据用户输入抓取什么资源的服务
  • 古老的SQL注入
  • 无耻的仿冒服务,DNS欺诈
  • 涉及HTML的,还要考虑跨站……

即使你做到了天衣无缝,还要考虑队友有时会掉链子:

  • glibc、openssl这些基础的库也会爆出漏洞,参见:Heartbleed
  • 同一台主机上的其它服务被攻陷

写完之后整个人都不好了



关于加密解密算法参见:加解密(Encryption)& 哈希(Hash)算法----入门指引 - 面向工资编程 - 知乎专栏
 

一、Encryption算法和Hash算法的区别

  • 信息论角度:
    • Encryption是可逆的,没有信息熵的改变
    • Hash是不可逆的,Hash一般会导致信息熵减小
  • 应用角度:
    • Encryption常被用来做基于密钥的数据加解密(AES、RSA、ECC)
    • Hash主要被用来做数字签名、数据校验(CRC、SHA、MD5)
  • 小白角度:
    • Encryption就是带密码的保险箱
    • Hash就是榨汁机,有去无回


二、加解密算法分为对称(Symmetric)、非对称(Asymmetry)两大类

  • 对称(Symmetric)加密
    •   对称加密的算法非常之多,一般使用中用AES就基本够用了。
非对称(Asymmetry)加密
  • 非对称加密算法,就是加密、解密的密钥分为两组,并且互相不能反推。这种算法在现实中很难有什么事物可以类比。大致就是通过某种算法可以生成一个密钥对k1、k2,用k1加密之后的密文只能用k2解密,反之亦然。
    非对称加密算法从原理上讲常用的有两种:
  • 基于因数分解的算法
    • RSA、DSA是此类算法中的代表,Linux系统的SSH就是基于这两种算法进行文件key auth。前几年一般建议RSA至少要达到1024位密钥才能保证抵御暴力破解,但由于GPU和超级计算机的算力提升,现在密钥长度建议2048位了。
  • 椭圆曲线算法(ECC)
  • 非对称加密算法非常酷,但它有一个致命的缺点:慢。RSA加密的速度大致是AES的1/30左右。所以我们不可能在所有场合都采用这类加密算法。我们的程序猿前辈们就创造了SSL、TLS等加密体系:

 

三、加密体系

TLS的前身是SSL,HTTP + TLS = HTTPS


一旦客户端和服务器都同意使用TLS协议,他们通过使用一个握手过程协商出一个有状态的连接以传输数据[1]。通过握手,客户端和服务器协商各种参数用于建立安全连接:

1. 当客户端连接到支持TLS协议的服务器要求建立安全连接并列出了受支持的密码组合(加密密码算法和加密哈希函数),握手开始。

2. 服务器从该列表中决定加密和散列函数,并通知客户端。

3. 服务器发回其数字证书,此证书通常包含服务器的名称、受信任的证书颁发机构(CA)和服务器的公钥。

4. 客户端确认其颁发的证书的有效性。

5. 为了生成会话密钥用于安全连接,客户端使用服务器的公钥加密随机生成的密钥,并将其发送到服务器,只有服务器才能使用自己的私钥解密。

6. 利用随机数,双方生成用于加密和解密的对称密钥。

7. 这就是 TLS 协议的握手,握手完毕后的连接是安全的,直到连接(被)关闭。如果上述任何一个步骤失败,TLS 握手过程就会失败,并且断开所有的连接。

 

五、盐的重要性

之前在这篇文章中提到过,如果单纯的把文件按块去加密,即使采用最强壮的算法也会存在一个很明显的漏洞,这里不再赘述,参见:用已知加密算法AES加密文本123,得到密文xxx,问能否根据密文、加密算法、原文本123直接推导出密钥是什么? - auxten 的回答



关于哈希函数的选用:

工作中发现,很多人对哈希函数的了解仅限于MD5。例如,在做数据库的分库分表的时候,可能需要对hostname做一次哈希再去取模,这里采用MD5就显得过于浪费CPU。要知道MD5平均会将每个Byte进行6.8次运算代入。

如果只是需要利用哈希的离散型,完全可以采用更轻的哈希算法



互联网服务器的实现过程需要考虑哪些安全问题 & 加解密及哈希知识点

标签:glib   targe   关闭   改变   实现   hostname   byte   环境   art   

原文地址:http://www.cnblogs.com/charlesblc/p/6341363.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!