盒子
盒子
文章目录
  1. 互联网通信安全
    1. 一些基本概念
      1. SSL/TLS, OpenSSL, HTTPS
      2. PKI, CA 和 Certificate
    2. 加密算法
    3. 解决方案
      1. 内容:数字证书,HTTPS,SSL/TLS 协议
    4. 什么是OpenSSL
    5. Openssl 操作指南
      1. 直接加解密
    6. OpenSSL CA 配置文件与格式
    7. 生成密钥对
    8. 数字证书的基础知识
  2. Certificate Authority (CA)
    1. 生成自签证书
  3. 颁发证书 ( 其他用户用OpenSSL 申请证书)
  • 创建目录
  • 生成公钥 扩展名随便取
  • 提取公钥
    1. session的恢复
  • (no title)

    互联网通信安全

    两大主题:身份认证和数据安全

    • 身份认证: 对方要能证明其身份 (数字签名和数字证书)
    • 数据安全: 如何保证密码传输过程中不会被别人窃取 (加解密)

    一些基本概念

    SSL/TLS, OpenSSL, HTTPS

    1. SSL/TLS
      SSL是在客户端和服务器之间建立一条SSL安全通道的安全协议
    2. OpenSSL
      OpenSSL是TLS/SSL协议的开源实现,提供开发库和命令行程序
    3. HTTPS
      常说的HTTPS是HTTP的加密版,底层使用的加密协议是SSL

      PKI, CA 和 Certificate

    4. PKI (Public Key Infrastructure)
      PKI 就是 Public Key Infrastructure 的缩写,翻译过来就是公开密钥基础设施。它是利用公开密钥技术所构建的,解决网络安全问题的,
      普遍适用的一种基础设 施;是一种遵循既定标准的密钥管理平台,它能够为所有网络应用提供加密和数字签名等密码服务及所必需的密钥和证书管理体系。

      PKI既不是一个协议,也不是一个软件,它是一个标准,在这个标准之下发展出的为了实现安全基础服务目的的技术统称为PKI。可以说CA(认证中心)是
      PKI的核心,而数字证书是PKI的最基本元素,还有如apache等服务器、浏览器等客户端、银行等应用,都是pki的组件。

    5. CA
      CA 机构,又称为证书认证中心 (Certificate Authority) 中心,是一个负责发放和管理数字证书的第三方权威机构,它负责管理PKI结构下的
      所有用户(包括各种应用程序)的证书,把用户的公钥和用户的其他信息捆绑在一起,在网上验证用户的身份。CA机构的数字签名使得攻击者不能伪造和篡改证书。

      认证中心主要有以下5个功能:

      证书的颁发:接收、验证用户(包括下级认证中心和最终用户)的数字证书的申请。可以受理或拒绝
      证书的更新:认证中心可以定期更新所有用户的证书,或者根据用户的请求来更新用户的证书
      证书的查询:查询当前用户证书申请处理过程;查询用户证书的颁发信息,这类查询由目录服务器ldap来完成
      证书的作废:由于用户私钥泄密等原因,需要向认证中心提出证书作废的请求;证书已经过了有效期,认证中心自动将该证书作废。

      认证中心通过维护证书作废列表 (Certificate Revocation List,CRL) 来完成上述功能。
      

      证书的归档:证书具有一定的有效期,证书过了有效期之后就将作废,但是我们不能将作废的证书简单地丢弃,因为有时我们可能需要

      验证以前的某个交易过程中产生的数字签名,这时我们就需要查询作废的证书。
      
    6. Certificate
      3.1 X.509 标准
      PKI的标准规定了PKI的设计、实施和运营,规定了PKI各种角色的”游戏规则”,提供数据语法和语义的共同约定。
      x.509是PKI中最重要的标准,它定义了公钥证书的基本结构,可以说PKI是在X.509标准基础上发展起来的。

      • SSL公钥证书
      • 证书废除列表CRL(Certificate revocation lists 证书黑名单)

      另外一个常用的标准是PKCS#12,通常采用pfx,p12作为文件扩展名,openssl和java的keytool工具都可以用作
      生产此类格式的证书。

      3.2 SSL/TLS 公钥证书格式

      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      21
      22
      23
      24
      25
      26
      27
      28
      29
      30
      31
      32
      33
      34
      35
      36
      37
      38
      39
      40
      41
      42
      43
      44
      45
      46
      47
      48
      49
      50
      51
      52
      53
      54
      55
      56
      57
      58
      59
      60
      61
      62
      63
      64
      65
      66
      67
      68
      69
      70
      71
      72
      73
      74
      75
      76
      77
      78
      79
      80
      81
      82
      83
      84
      85
      86
      87
      88
      89
      90
      91
      92
      93
      94
      95
      96
      97
      98
      99
      100
      101
      102
      103
      104
      105
      106
      107
      108
      109
      110
      111
      112
      113
      114
      115
      116
      117
      118
      119
      Certificate:
      Data:
      Version: 3 (0x2)
      1. 证书版本号(Version)
      版本号指明X.509证书的格式版本,现在的值可以为:
      1) 0: v1
      2) 1: v2
      3) 2: v3
      也为将来的版本进行了预定义

      Serial Number: 9 (0x9)
      2. 证书序列号(Serial Number)
      序列号指定由CA分配给证书的唯一的"数字型标识符"。当证书被取消时,实际上是将此证书的序列号放入由CA签发的CRL中,
      这也是序列号唯一的原因。

      Signature Algorithm: sha256WithRSAEncryption
      3. 签名算法标识符(Signature Algorithm)
      签名算法标识用来指定由CA签发证书时所使用的"签名算法"。算法标识符用来指定CA签发证书时所使用的:
      1) 公开密钥算法
      2) hash算法
      example: sha256WithRSAEncryption
      须向国际知名标准组织(如ISO)注册

      Issuer: C=CN, ST=GuangDong, L=ShenZhen, O=COMPANY Technologies Co., Ltd, OU=IT_SECTION, CN=registry.example.com.net/emailAddress=zhouxiao@example.com.net
      4. 签发机构名(Issuer)
      此域用来标识签发证书的CA的X.500 DN(DN-Distinguished Name)名字。包括:
      1) 国家(C)
      2) 省市(ST)
      3) 地区(L)
      4) 组织机构(O)
      5) 单位部门(OU)
      6) 通用名(CN)
      7) 邮箱地址

      Validity
      Not Before: Feb 11 06:04:56 2015 GMT
      Not After : Feb 8 06:04:56 2025 GMT


      5. 有效期(Validity)
      指定证书的有效期,包括:
      1) 证书开始生效的日期时间
      2) 证书失效的日期和时间
      每次使用证书时,需要检查证书是否在有效期内。

      Subject: C=CN, ST=GuangDong, L=ShenZhen, O=TP-Link Co.,Ltd., OU=Network Management, CN=172.31.1.210
      6. 证书用户名(Subject)
      指定证书持有者的X.500唯一名字。包括:
      1) 国家(C)
      2) 省市(ST)
      3) 地区(L)
      4) 组织机构(O)
      5) 单位部门(OU)
      6) 通用名(CN)
      7) 邮箱地址

      Subject Public Key Info:
      Public Key Algorithm: rsaEncryption
      Public-Key: (2048 bit)
      Modulus:
      00:a4:b0:dd:eb:c1:cf:5d:47:61:a6:ea:ef:8b:aa:
      4b:f0:b4:2c:d8:96:c7:7c:ac:fa:c7:35:88:53:d0:
      ...
      8a:76:dc:8f:8c:44:c8:0b:3c:36:88:5f:01:f0:44:
      4e:81:e6:7a:2b:ff:ba:da:33:a5:27:11:c6:f0:08:
      6e:f3
      Exponent: 65537 (0x10001)
      7. 证书持有者公开密钥信息(Subject Public Key Info)
      证书持有者公开密钥信息域包含两个重要信息:
      1) 证书持有者的公开密钥的值
      2) 公开密钥使用的算法标识符。此标识符包含公开密钥算法和hash算法。

      X509v3 extensions:
      8. 扩展项(extension)
      X.509 V3证书是在v2的基础上一标准形式或普通形式增加了扩展项,以使证书能够附带额外信息。标准扩展是指
      由X.509 V3版本定义的对V2版本增加的具有广泛应用前景的扩展项,任何人都可以向一些权威机构,如ISO,来
      注册一些其他扩展,如果这些扩展项应用广泛,也许以后会成为标准扩展项。

      X509v3 Basic Constraints:
      CA:FALSE

      Netscape Comment:
      OpenSSL Generated Certificate

      10. 证书持有者唯一标识符(Subject Unique Identifier)
      持有证书者唯一标识符在第2版的标准中加入X.509证书定义。此域用在当同一个X.500名字用于多个证书持有者时,
      用一比特字符串来唯一标识证书持有者的X.500名字。可选。
      X509v3 Subject Key Identifier:
      07:C6:87:B7:C1:1E:28:E8:96:3F:EB:40:1E:82:41:45:CA:81:B6:3D

      9. 签发者唯一标识符(Issuer Unique Identifier)
      签发者唯一标识符在第2版加入证书定义中。此域用在当同一个X.500名字用于多个认证机构时,用一比特字符串
      来唯一标识签发者的X.500名字。可选。
      X509v3 Authority Key Identifier:
      keyid:A4:C2:14:6A:39:D1:95:1E:BD:DF:3B:92:4A:5C:12:42:1B:BC:53:B8



      Signature Algorithm: sha256WithRSAEncryption
      11. 签名算法(Signature Algorithm)
      证书签发机构对证书上述内容的签名算法

      12. 签名值(Issuer's Signature)
      证书签发机构对证书上述内容的签名值
      0c:c6:81:70:cd:0a:2d:94:4f:cb:a4:1d:ef:9e:8e:e4:73:ae:
      50:62:a8:9c:64:ef:56:0f:41:fe:6b:b4:d3:07:37:39:2c:ed:
      ...
      6f:62:61:b8:03:d7:97:31:ab:05:44:20:07:65:8b:ad:e2:cc:
      ad:65:73:f6:82:0f:9e:65:d0:ae:b7:1e:fd:9f:c1:d7:41:6c:
      0f:06:95:ee


      -----BEGIN CERTIFICATE-----
      MIIEMDCCAxigAwIBAgIBCTANBgkqhkiG9w0BAQsFADCBtTELMAkGA1UEBhMCQ04x
      EjAQBgNVBAgMCUd1YW5nRG9uZzERMA8GA1UEBwwIU2hlblpoZW4xJjAkBgNVBAoM
      ...
      ujwwRar6pPzusO95WuS93HsNmL2ZFZ63DS4LcW9iYbgD15cxqwVEIAdli63izK1l
      c/aCD55l0K63Hv2fwddBbA8Gle4=
      -----END CERTIFICATE-----

    用在HTTPS加密

    HASH 算法:SHA1, SHA2, MD5, SHA256

    加密算法

    1. 对称加密(双向加密): 加密与解密使用同一密码,对明文使用密码加密后,对方可以通过同一密码进行反向解密.

    常见的加密算法有 DES(56bits)、3DES、AES(128bits)、Blowfish、Twofish、IDEA、RC6、CAST5、Serpent等等.
    AES,RC4, 3DES

    此种加密一般都是 将原文分割成固定大小的数据块,对这些块进行加密(ECB,CBC).
    此种方式加密容易遭受 字典攻击,同时解密方需要得到加密密码,中间可能涉及密码传输泄露问题.

    1. 非对称加密
      非对称加密与对称加密相反,其加密解密可使用不同的密码,常见的如 RSA、EIGmal、DSA/DSS 等. 在非对称加密中,有一种比较特殊的加密叫做单向加密,
      单向机密也称消息摘要算法,其主要目的是提取消息特征码,加密后的密文不可逆。常见的单向加密算法有 : MD5、SHA1、SHA512、CRC-32(循环冗余校验码)
      等;单向加密有两个重要的特性 : 定长输出、雪崩效应;定长输出可以理解为 无论消息体多大,最终输出加密后结果长度一致,雪崩效应顾名思义,即消息体的
      微小变化,会导致加密结果的巨大变化。

    2. 公钥加密
      公钥加密时会有两个文件,即一个公钥一个私钥;并且公钥与私钥成对出现,其特性是 使用公钥加密的内容必须使用与其匹配的私钥解密,反之亦然。

    解决方案

    1. 证明自己身份的文件
      身份认证问题,即 “支付宝要能证明他是支付宝”;纵观以上3中加密算法,比较适合做身份认证的就是 公钥加密,即在互联网上从未通讯过的主机想向对方
      证明自己的身份,只需先生成一对密钥,然后将公钥放在互联网上大家可任意获取,私钥自己保留;需要证明身份时只需用自己的私钥加密一段信息发给
      对方,对方若能使用其公钥解密,就能证明其身份。

    2. 证明用来证明自己身份的文件是真实的
      如何保证从互联网上获取的公钥就是对方的,而不是别人恶意放到互联网上的假冒公钥?
      解决方案就是 大家找一个公认的知名机构,把公钥全部放到这个机构那,然后谁需要谁从那里下载,此时这个机构称之为 CA,CA 为每个使用者颁发一个
      证书,证书中包含使用者的公钥和CA 的私钥签名,以及一些使用者信息;同时证书具有级联信任关系,即 我们信任了一家 CA 的根证书,那么由其颁发的
      其他证书将都被信任,类似于一棵树的结构,一旦我们信任了根节点那么以下所有子节点将全部被信任。

    1. 数据传输过程中的加密问题
      传输数据,那么数据内容肯定需要双向加密才可以被接收方解密读取,但是很大的问题是 双向加密时,解密方需要知道解密密码;而将密码在互联网上
      传输明显是不明智的,此时出现了另一种解决方案,即 密钥交换算法(Diffie-Hellman 算法),专门用于在互联网上传输密钥信息。
    1. 数据完整性
      对于完整性最好的应用就是采用单向加密即消息摘要算法,提取数据的特征码;简单地说就是每发送一段数据,就对发送的数据做一次数据特征提取,
      然后将特征码一并发送,接收方接收到数据并解密后可对其使用同样的算法进行特征码提取比对,如果计算结果不一致则证明数据被篡改,直接丢弃即可。

    内容:数字证书,HTTPS,SSL/TLS 协议

    1. HTTPS为什么安全?HTTPS是如何保证安全的?
      使用非对称加密来交换一个密钥来进行对称加密,这个过程称为SSL/TLS的四次握手。用对称加密算法来进行通信
      master_secret = PRF(pre_master_secret, “master secret”, ClientHello.random + ServerHello.random)[0 .. 47]

    随机数为什么是三个?
    这是由于SSL/TLS设计,就假设服务器不相信所有客户端都能够提供完全随机数,假如某个客户端提供的随机数不随机的话,就大大增加了“对话密钥”
    被破解的风险,所以由三组随机数组成的最后的随机数,保证了随机数的随机性,以此来保证每次生成的“对话密钥”安全性

    1. 如何保证非对称加密时的安全性?
      服务器端发送证书来传递非对称加密的公钥,保证了公钥和私钥的保密性

    2. 客户端怎么知道服务器端证书是不是真的?/ 客户端具体是如何验证SSL证书的?
      客户端根据CA证书的公钥校验证书的数字签名来保证其合法性。

    为了抵御中间人 man-in-the-middle 攻击,SSL证书需要由可信的SSL证书颁发机构颁发,形成一个证书链
    (比如Gmail的证书链为:最底层为网域 mail.google.com,上一层为Thawte SGC CA证书颁发机构,
    最顶层为很有名的VeriSign证书颁发机构)。

    那么,浏览器除了需要验证域和有效期外,还要检查证书链中的上级证书公钥是否有效,上级的上级证书公钥是否有效,直至根证书公钥为止。这样就可以有效避免中间人攻击了.

    根证书公钥都是预装在操作系统中的,黑客如果不是暴力破解,无法得到根证书的私钥。如果黑客自己生成一个私钥,浏览器验证根证书公钥的时候发现无法通过操作系统中预装的公钥加密数据后使用这个私钥进行解密,从而判定这个公钥是无效的。这个方案也是现在https通讯通常的方案。

    现在所有的浏览器正在使用的https通讯方案就无懈可击了吗?答案仍是否定的。我们可以看到,在后一个方案中,https的安全性需要在证书颁发机构公信力的强有力保障前提下才能发挥作用。如果证书颁发机构在没有验证黑客为mail.google.com的持游者的情况下,给黑客颁发了网域为mail.google.com的证书,那么黑客的中间人攻击又可以顺利实施然而,不验证域名持有者就颁发证书的情况在国外几乎不会发生,但是在国内就不一定了。针对破解目标,国内证书颁发机构WoSign(在此只是举例国内比较有名的证书颁发机构WoSign,并不代表WoSign今后一定会这么做)很有可能为了上级要求颁发了证书给非域名持有者的黑客,从而使得破解目标的Gmail密码被黑客截取。

    证书验证失败的原因
    1、SSL证书不是由受信任的CA机构颁发的(注意这种情况并不一定说明有SSL劫持发生)
    2、证书过期
    3、访问的网站域名与证书绑定的域名不一致

    1. 证书内容被篡改
    2. 客户端没有保存认证服务器端证书的根证书
    3. 客户端拥有认证服务器证书的根证书,但是服务器被防火墙隔离,防火墙在收到来自客户端的SSL连接请求时候返回
      防火墙的证书,需要查看根证书内容 openssl x509 -text -in rootCA.pem, 查看到根证书签发者信息 Issuer: O=Equifax

    4. 客户端的CA证书不会被伪造或泄露么?
      CA证书时默认预装到浏览器和操作系统中的,所以CA证书的公钥是安全的。

    为什么证书是安全的?
    什么是证书
    数字证书就是互联网通讯中标志通讯各方身份信息的一串数字,提供了一种在Internet上验证通信实体身份的方式,数字证书不是数字身份证,而是身份认证机构盖在数字身份证上的一个章或印(或者说加在数字身份证上的一个签名)。它是由权威机构——CA机构,又称为证书授权(Certificate Authority)中心发行的,人们可以在网上用它来识别对方的身份。
    数字证书的格式普遍采用的是X.509V3国际标准,一个标准的X.509数字证书包含以下一些内容:

    证书的版本信息;
    证书的序列号,每个证书都有一个唯一的证书序列号;
    证书所使用的签名算法;
    证书的发行机构名称,命名规则一般采用X.500格式;
    证书的有效期,通用的证书一般采用UTC时间格式,它的计时范围为1950-2049;
    证书所有人的名称,命名规则一般采用X.500格式;
    证书所有人的公开密钥;
    证书发行者对证书的签名。
    证书里的公钥的作用?
    证书里的签名的作用?
    数字证书的签发机构CA,在接收到申请者的资料后进行核对并确定信息的真实有效,然后就会制作一份符合X.509标准的文件。证书中的证书内容包含的持有者信息和公钥等都是由申请者提供的,而数字签名则是CA机构对证书内容进行hash加密后得到的,而这个数字签名就是我们验证证书是否是有可信CA签发的数据。

    CA.png

    证书的产生

    certification_production.png

    证书的类型
    实际上,我们使用的证书分很多种类型,SSL证书只是其中的一种。证书的格式是由X.509标准定义。SSL证书负责传输公钥,是一种PKI(Public Key Infrastructure,公钥基础结构)证书。
    我们常见的证书根据用途不同大致有以下几种:
    1、SSL证书,用于加密HTTP协议,也就是HTTPS。
    2、代码签名证书,用于签名二进制文件,比如Windows内核驱动,Firefox插件,Java代码签名等等。
    3、客户端证书,用于加密邮件。
    4、双因素证书,网银专业版使用的USB Key里面用的就是这种类型的证书。
    这些证书都是由受认证的证书颁发机构——我们称之为CA(Certificate Authority)机构来颁发,针对企业与个人的不同,可申请的证书的类型也不同,价格也不同。CA机构颁发的证书都是受信任的证书,对于SSL证书来说,如果访问的网站与证书绑定的网站一致就可以通过浏览器的验证而不会提示错误。

    证书的安全问题
    如果让证书安全,那么就需要让客户端拿到的证书是真正想要的证书,即不能让证书被冒充或者被篡改。
    那么如何保证这一点呢?

    如果证书自己有一个id
    证书的这个id无法被伪造
    客户端知道自己想要的证书id是多少
    如果做到了这三点就能保证证书的安全性了。上面说提到的id就是证书的数字签名。那么什么是数字签名?

    数字签名(digital signature)
    数字签名是证书的防伪标签,是将待签名内容通过哈希和私钥加密处理后生成的。目前使用最广泛的 SHA-RSA 数字签名的制作和验证过程如下:

    数字签名的签发。首先是使用哈希函数对待签名内容进行安全哈希,生成数字摘要,然后使用CA自己的私钥对数字摘要进行加密。
    数字签名的校验。使用CA的公钥解密签名,然后使用相同的签名函数对待签名证书内容进行签名并和服务端数字签名里的签名内容进行比较,如果相同就认为校验成功。
    签发:待签名内容 -> 哈希 -> 数字摘要 -> CA私钥加密 -> 数字签名
    校验:

    数字签名 -> CA公钥解密 -> 数字摘要1
    待签名内容 -> 哈希 -> 数字摘要2
    比较「数字摘要1」和「数字摘要2」是否相等

    CerValiate.png

    这里有几点需要说明:

    数字签名签发和校验使用的密钥对是 CA 自己的公私密钥,跟证书申请者提交的公钥没有关系。
    数字签名的签发过程跟公钥加密的过程刚好相反,即是用私钥加密,公钥解密。
    现在大的 CA 都会有证书链,证书链的好处一是安全,保持根 CA 的私钥离线使用。第二个好处是方便部署和撤销,即如果证书出现问题,只需要撤销相应级别的证书,根证书依然安全。
    根 CA 证书都是自签名,即用自己的公钥和私钥完成了签名的制作和验证。而证书链上的证书签名都是使用上一级证书的密钥对完成签名和验证的。
    那么问题又来了。
    CA的私钥和公钥是安全的吗?可以被冒充吗?

    CA的安全性
    从根CA开始到直接给客户发放证书的各层次CA,都有其自身的密钥对。CA中心的密钥对一般由硬件加密服务器在机器内直接产生,并存储于加密硬件内,或以一定的加密形式存放于密钥数据库内。加密备份于IC卡或其他存储介质中,并以高等级的物理安全措施保护起来。密钥的销毁要以安全的密钥冲写标准,彻底清除原有的密钥痕迹。需要强调的是,根CA密钥的安全性至关重要,它的泄露意味着整个公钥信任体系的崩溃,所以CA的密钥保护必须按照最高安全级 的保护方式来进行设置和管理。

    CA的私钥是自己靠上述方法保管的,不对外公开。
    CA的公钥是厂商跟浏览器和操作系统合作,把公钥默认装到浏览器或者操作系统环境里。比如firefox 就自己维护了一个可信任的 CA 列表,而chrome 和 IE 使用的是操作系统的 CA 列表。

    1. 分析HTTPS连接建立全过程
    2. 理解HTTPS

      1. 什么是https
        浏览器和网站之间的通信,浏览器要验证颁发证书的机构是否合法,证书中包含的网站地址是否和正在访问的地址一致等,如果
        证书受信任,浏览器里面会显示一个小锁头, 否则会给出证书不守信的提示。
      2. 什么是SSL/TLS
      3. 为什么要有https

        1. http 和 https 协议的区别

        Https协议需要用到CA申请证书,
        Http是超文本传输协议,信息是明文传输,https 则是具有安全性的ssl加密传输协议
        http和https用的接口不一样,http是80, https 是443
        http的链接是无状态的,
        https是由ssl + http协议构成的可以进行加密传输,身份认证的网络协议,比 http协议要安全

    不加密的通行带来了三大风险:

    1. 窃听风险 eavesdropping : 第三方可以获知通信内容
    2. 篡改风险 tampering: 第三方可以修改通信内容
    3. 冒充风险 pertending: 第三方可以冒充他人身份参与通信

      1. https保证安全的原理

    SSL/TLS协议就是为了解决这三大风险而设计的,希望达到:

    1. 所有信息都机密传播,第三方无法窃听
    2. 具有校验机制,一旦被篡改,通信双方会立刻发现
    3. 配备身份证书,防止身份被冒充

      1. 为什么证书是安全的?
        5.1. 什么是证书
        5.2. 证书的产生
        5.3. 证书的类型
        5.4. 证书的安全问题
        5.4.1. 数字签名(digital signature)
        5.4.2. CA的安全性
        5.5. 证书验证失败的原因
      2. 客户端具体是如何验证SSL证书的
      3. 涉及到的算法
      4. 总结
      5. Reference
    1. SSL/TLS 原理详解

    SSL/TLS

    1. The first few milliseconds of an HTTPS connection

    什么是OpenSSL

    OpenSSL是一个安全套接字层密码库,其包括常用的密码算法、常用的密钥生成和证书封装管理功能及SSL协议,并提供了丰富的应用程序以供测试。

    OpenSSL 是一个开源项目,其组成主要包括一下三个组件:
    openssl:多用途的命令行工具。
    openssl命令工具有两种运行模式:交换模式和批处理模式。
    直接输入openssl回车即可进入交互模式,
    而输入带命令选项的openssl命令则进行批处理模式。
    libcrypto:加密算法库
    libssl:加密模块应用库,实现了ssl及tls
    openssl可以实现:秘钥证书管理、对称加密和非对称加密

    术语

    1
    2
    3
    4
    5
    *.key:  私有的密钥
    *.csr: 证书签名请求(证书请求文件),含有公钥信息,certificate signing request的缩写
    *.crt: 证书文件,certificate的缩写
    *.crl: 证书吊销列表,Certificate Revocation List的缩写
    *.pem:用于导出,导入证书时候的证书的格式,有证书开头,结尾的格式

    公钥私钥的核心功能
    加密: 公钥用于对数据进行加密,私钥用于对数据进行解密
    签名: 私钥用于对数据进行签名,公钥用于对签名进行验证

    Openssl 操作指南

    直接加解密

    OpenSSL 使用子命令 enc 实现加密,命令格式如下

    openssl enc -算法 -salt -a -salt -in 输入文件 -out 输出文件 -k passwd
    如下为加密一个文件示例

    openssl enc -aes-256-ecb -a -salt -in /etc/profile -out ~/test -k test123
    -a 选项用于将加密后内容以 base64 格式输出,加密后内容如下

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    U2FsdGVkX1/tVWQ7cGR5rTLU9Phnx7csis12ukuGpZTWx7sDiJ8Qdb4Jn8hvShnW
    7gPouyOwJlKufoDHXT2hqOnw/i8Rf5QisLc+EOXgUWDFun3AqHte6YmNbelDFchu
    hDsph4Vq7TNBmZ/C1LHSCnMoA39qHBWxyrIstpOWs5TWkdPjDgEVZkIXNiWIwoRF
    CDVv7AuZXO9qF3sMb4fLWPF9cM7FkbvGkkhzBJZ0dAdq8DetKaZyjOX4UfeWPSav
    U61t9s7hlmjEPmXpUSSfnO8/7u0B/EEnujpkwyNZXbQBcQ9QFDh7x1vdzQIAuMRw
    0SLsVm1OSOifvMOpOAJCmvhExrKsznWgQlQabLOWsr29yrs0YBuwSl6oUSf8Qx1S
    3z/GC7l13zzmHwXJTgPRe0WzdLYsy6GMj2/0DveLvcXT/cXGid69tzIf4JaczIEX
    zSS4N12C3CFS/60poXZmiwoNsC3n6ESBf3dZum6LKA9sNPdxveb/RTZ4KYl/iw9S
    NgAqNGa9Yp1xdyl2NBaruvDxVAGbwC+rGn9UjbIYbEdT7ZjKPjJ6BP8yzwv6jnOU
    3E58UVIuIEVWJY3kF77+Vk99JuQepFRGX9sHYdafQR7AISiS88eipn6qkMMDmrkT
    kwZtebWyhvmWTZABOa7tckzzYxJ/Ke1jkBudasUJr9RUEiNNmSASdRr0dlZvM/tS
    COuPeNo8ZU7ad/yd/OpvPKShn9Hh9oXCKSB4vl/DQVefVXWAaTp49FFAGFrQThiQ
    rAwHwrJ/N2ab0Do0iArctNTqz5u7MtEHwVtFsV45YJfAGQRwTg06Y6qKjhgWmBjX
    EGNGbP7c0A1SiI/g8maKl3ciTwWPWXCcpf14MFcYBvjpA7EVYSYTh7hSxzUtY0gk
    l3EUVrqnY0M8u+0LBgAcrA==

    4.2.2、解密操作
    解密操作与加密基本相同,只不过需要加上 -d 选项,代表解密,命令格式如下

    1
    openssl enc -算法 -salt -d -a -in 输入文件 -out 输出文件 -k passwd

    如下为解密一个文件的示例

    1
    openssl enc -aes-256-ecb -salt -d -a -in test -out test1 -k test123

    解密后文件即为原来的 /etc/profile 文件内容

    OpenSSL CA 配置文件与格式

    生成密钥对

    生成密钥对
    生成私钥: openssl genrsa -out private.key 2048

    genrsa 产生RSA密钥命令。
    -out 输出路径,这里指private/server.key.pem。
    2048 指RSA密钥长度位数,默认长度为512位。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    lyu@ovm_h2o-lyu:~/Desktop$ openssl genrsa -out server.key 2048
    Generating RSA private key, 2048 bit long modulus
    .......................+++
    ...........+++
    e is 65537 (0x10001)

    lyu@ovm_h2o-lyu:~/Desktop$ cat server.key
    -----BEGIN RSA PRIVATE KEY-----
    MIIEpQIBAAKCAQEA6vT9Z//kaSEEC5X3ngZUmzcXIMfBdGN1AOM8UANANDiD3kPm
    Pdc4oVogxEs1n3zDWr1ltdxoFnqLws9DYaqsbuuej+ZO3ZEFrhq7ElzdQGuvkSNa
    vqUOZvMlDFixdrn6hep5na2KtEP+q2aPTsA2/aRvXYhNeKhfjLhChWIbXknTj7UJ
    XVXDX0bWDJlm9/eNScCJWuJ6Krfe+nmfdcfAKlOK+OU+rXjCoETv6rYgyLuLxHJP
    qj8g6c6wv1f7s9g9J83HegjvqICRf25abfrAh+9pnAQ9+/CKHvu3BtHz0Xv7lMsh
    AlnRegBlDeGcrv/OZ9+qPsrnewjhTNJn9bxFeQIDAQABAoIBAEdt+6wma3ZahzRO
    f10XZ5lYgjuA/xs3MVb3vlpE4rv9gnmMAu9CAwFquRN0GfVGpM1tTwKe4zYSQ3MS
    N9X1YT7HewkcZ1WMxUFM9xp6CPmQw2tIaEoVO++oc9bxD+KcX8Feq2J4Y/axxTau
    k1rJrO4nk4PH8GWCKqpJSk/qp49eJUgWueOmV4FfRcjLCsKffUM/8jCeWu+iWwKV
    lJh/jhShSOpk9x2k8ObYRk+U8yBWi6K+roPFdKrwE/wragOtX+ULB+44jk1xV6sc
    9snkOKkdmRrBloG+F2REfyf8PNypndxyeveyT3ywlsQkcCK52vYIpLamw/tBoK3S
    AARqZgECgYEA9ZzSXa4a8wvwssGVKaQJaQqt3DN3UGElfKfNAmVceumeFysu15Y0
    k/OwR4AS03y9Nxta722ganaDztpVYPUg1t+c6B0eUPcW8NZQk9U+aPgtNz/pbkNt
    pdmkBYO4vAnvQL7wL3YYMw9OlOGs3TknLUvrePefEopBA+csJUlTIXECgYEA9OTN
    krosiWdYTqt5lK2wXavPVH1lXH0uilkKKdxNYHBB8n9CVSv6WJBmpOxrqE0ncoEt
    xKG3BFxPKXwr5fKvVgKQZ2PmZhTDqGpawe8yASYcugnwwPqZFHMIzxwPB94Ulin8
    JwW9B4hzlJib5QqB2jX3CQtnuZKARaJC8OyFYIkCgYEA3fbymlzM2BdTWIjf37jy
    FC7lfpo4Wrjgou4WtPKbiCz2hSOueoCxVYAmMAfLe7tAWLvtC3H8RhqC9f6UqEH/
    gpClgZNHIY6b+d0FBwTxGPYoDsVAlTh0sCynMaCf47fqs42bDJliN0q/DoeArJCJ
    GkOBM1o9NQkixn81gyDn8tECgYEAy7BbREVRsd+hVZ3OfFmTLfYvdojt++WrBitV
    BshUG3iDgZ1ToN/5VByXI2n5iXzS6KyFUt1nClt1BH5hTNtz9sgfL7+p7RIsQzJi
    1peLMeVvU1XdR8Wn+ZhMpWcjIVoYKWY2coaVWWSnLdtZH0KECumD1aQE3Bb8Ve7G
    Wvl/XnECgYEAvGwAMZUP3KZjIZ6EsdZU2JEuA9nLymeUEAB5oDlntHu3hFqv6jja
    BB7SIP8DKOwQJiqNlq7MC1iAUkDdSKk0tOod4IBj8fBDOBNrdMM/4nLnWUSfZLG1
    tTtIXXrXhU0KxDh1h01LXgOBRkfSBOM/evuCaOruWZi9iexGHJbik/s=
    -----END RSA PRIVATE KEY-----

    导出私钥对应的公钥: openssl rsa -in private.key -pubout -out public.key

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    lyu@ovm_h2o-lyu:~/Desktop$ openssl rsa -pubout -in server.key 
    writing RSA key
    -----BEGIN PUBLIC KEY-----
    MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6vT9Z//kaSEEC5X3ngZU
    mzcXIMfBdGN1AOM8UANANDiD3kPmPdc4oVogxEs1n3zDWr1ltdxoFnqLws9DYaqs
    buuej+ZO3ZEFrhq7ElzdQGuvkSNavqUOZvMlDFixdrn6hep5na2KtEP+q2aPTsA2
    /aRvXYhNeKhfjLhChWIbXknTj7UJXVXDX0bWDJlm9/eNScCJWuJ6Krfe+nmfdcfA
    KlOK+OU+rXjCoETv6rYgyLuLxHJPqj8g6c6wv1f7s9g9J83HegjvqICRf25abfrA
    h+9pnAQ9+/CKHvu3BtHz0Xv7lMshAlnRegBlDeGcrv/OZ9+qPsrnewjhTNJn9bxF
    eQIDAQAB
    -----END PUBLIC KEY-----

    数字证书的基础知识

    问题两个:

    1. 证书的安全性,Client端是如何验证证书合法性的,这个证书第三方无论如何都伪造不了吗?
    2. 对称加密密钥的安全性,生成的master secret密钥第三方为什么拿不到?

      Certificate Authority (CA)

      CA是专门签发证书的权威机构,处于证书的最顶端。自签是用自己的私钥给证书签名,CA签发则是用CA的私钥给自己的证书签名来保证证书的可靠性

      CA根证书的生成步骤:
      生成CA私钥(.key)–>生成CA证书请求(.csr)–>自签名得到根证书(.crt)(CA给自已颁发的证书)。

      生成私钥: openssl genrsa -out ca.key 2048
      生成证书请求: openssl req -new -key ca.key -out ca.csr
      自签名: openssl x509 -req -days 365 -in ca.csr -signkey ca.key -out ca.crt

      以上操作合并操作如下:
      openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ca.key -out ca.crt

    重要参数含义如下:
    req
    -x509
    -nodes 本option被set的话,生成的私有密钥文件将不会被加密
    -days 365

    查看自签名CA证书:openssl x509 -text -in ca.cert

    生成自签证书

    e.g.
    lyu@test:~/root-ca$ openssl req -nodes -config conf/openssl-root.cnf -days 1826
    -x509 -newkey rsa:1024 -out public/ca-root-cert.pem -outform PEM
    -keyout private/ca-root-key.pem

    Generating a 1024 bit RSA private key
    ................++++++
    ...............................++++++
    writing new private key to 'private/ca-root-key.pem'
    

    颁发证书 ( 其他用户用OpenSSL 申请证书)

    颁发证书就是用CA的秘钥给其他人签名证书,输入需要证书请求,CA的私钥及CA的证书,输出的是签名好的还给用户的证书.
    用户的证书请求信息填写的国家省份等需要与CA配置一致,否则颁发的证书将会无效。

    用户证书的生成步骤
    生成私钥(.key)–>生成证书请求(.csr)–>CA的私钥及CA的证书签名得到用户证书(.crt)

    e.g.

    同样,先生成一对密钥

    创建目录

    mkdir mycrt

    生成公钥 扩展名随便取

    openssl genrsa -out mritd.key 2048

    提取公钥

    openssl rsa -in mritd.key -pubout > mritd.public.key
    接下来要申请一个证书签署请求,信息要保证与 CA 创建时一致(具体可调整 openssl.cnf 配置文件),密码直接回车默认为空密码
    openssl req -new -key mritd.key -out mritd.csr
    最后使用 CA 进行签署即可(注意,要回到 demoCA 上一级目录),提示是否确认全部 y 即可
    openssl ca -in mycrt/mritd.csr -out mycrt/mritd.crt -days 3655
    最终生成的 mritd.crt 即为可用的证书

    生成密钥: openssl genrsa -out client.key 2048
    生成请求: openssl req -new -subj -key client.key -out client.csr
    签发证书:
    openssl x509 -req -days 3650 -sha1 -extensions v3_req
    -CA ca.cert -CAkey ca.key -CAserial ca.srl -CAcreateserial
    -in client.csr -out client.cert

    req 产生证书签发申请命令
    -new 表示新请求。
    -key 密钥,这里为client.key文件
    -out 输出路径,这里为client.csr文件
    -subj 指定用户信息

    x509 签发X.509格式证书命令。
    -req 表示证书输入请求。
    -days 表示有效天数,这里为3650天。
    -sha1 表示证书摘要算法,这里为SHA1算法。
    -extensions 表示按OpenSSL配置文件v3_req项添加扩展
    -CA 表示CA证书,这里为ca.cert
    -CAkey 表示CA证书密钥,这里为ca.key
    -CAserial 表示CA证书序列号文件,这里为ca.srl
    -CAcreateserial表示创建CA证书序列号
    -in 表示输入文件,这里为private/server.csr
    -out 表示输出文件,这里为certs/server.cer

    验证CA颁发的证书提取的公钥和私钥导出的公钥是否一致 openssl x509 -in server.cert -pubkey
    验证server证书openssl verify -CAfile ca.cert server.cert
    生成pem格式证书有时需要用到pem格式的证书,可以用以下方式合并证书文件(crt)和私钥文件(key)来生成 cat client.crt client.key > client.pem

    session的恢复

    session ID:
    每次对话都有一个编号 session ID, 如果对话中断,下次重新连接的时候,只要客户端给出这个编号,而且服务器有这个编号的记录(现在都用集群集中管理session),
    双方就可以重新使用已有的“对话密钥”, 而不必重新生成一把。双方就不再进行握手阶段剩余的步骤。

    优点是所有浏览器都支持,但是缺点在于session ID 往往只保留在一台服务器上。所以,如果客户端请求发送到另外一台服务器,就无法恢复对话。

    session ticket:就是解决session id 不足的问题,
    客户端不在发送session ID,而是发送一个服务器在上一次对话中发送过来的session ticket。 这个session ticket是加密的,只有服务器才能解谜,
    其中包括本次对话的主要信息,比如对话密钥和加密方法。当服务器收到session ticket 后,解谜后就不必重新生成对话密钥了。

    1. 附:数据加密的基础知识
      对称密钥加密
      对称密钥加密(一个密钥),也叫做共享密钥加密或机密密钥加密,使用发件人和收件人共同拥有的单个密钥。这种密钥既用于加密,也用于解密,叫做机密密钥。对称密钥加密是加密大量数据的一种行之有效的方法。

    对称密钥加密有许多种算法如DES,RC4,IDEA等,但所有这些算法都有一个共同的目的:以可还原的方式将明文 (未加密的数据转换为暗文。暗文使用加密密钥编码,对于没有解密密钥的任何人来说它都是没有意义的。由于对称密钥加密在加密和解密时使用相同的密钥,所以这种加密过程的安全性取决于是否有未经授权的人获得了对称密钥。

    衡量对称算法优劣的主要尺度是其密钥的长度。密钥越长,在找到解密数据所需的正确密钥之前必须测试的密钥数量就越多。需要测试的密钥越多,破解这种算法就越困难。

    公钥加密
    公钥加密使用两个密钥:一个公钥和一个私钥,这两个密钥在数学上是相关的。为了与对称密钥加密相对照,公钥加密有时也叫做不对称密钥加密。在公钥加密中,公钥可在通信双方之间公开传递,或在公用储备库中发布,但相关的私钥是保密的。只有使用私钥才能解密用公钥加密的数据。使用私钥加密的数据只能用公钥解密。下图中,发件人拥有收件人的公钥,并用它加密了一封邮件,但只有收件人掌握解密该邮件的有关私钥。
    openssl-encrpt01

    公钥算法的主要局限在于,这种加密形式的速度相对较低。实际上,通常仅在关键时刻才使用公钥算法,如在实体之间交换对称密钥时,或者在签署一封邮件的散列时(散列是通过应用一种单向数学函数获得的一个定长结果,对于数据而言,叫做散列算法)。将公钥加密与其它加密形式(如对称密钥加密)结合使用,可以优化性能,如数字签名和密钥交换。

    常用公钥算法:

    RSA:适用于数字签名和密钥交换。 是目前应用最广泛的公钥加密算法,特别适用于通过 Internet 传送的数据,RSA算法以它的三位发明者的名字命名。
    DSA:仅适用于数字签名。 数字签名算法 (Digital Signature Algorithm, DSA) 由美国国家安全署 (United States National Security Agency, NSA) 发明,已作为数字签名的标准。DSA 算法的安全性取决于自计算离散算法的困难。这种算法,不适用于数据加密。
    Diffie-Hellman:仅适用于密钥交换。 Diffie-Hellman 是发明的第一个公钥算法,以其发明者 Whitfield Diffie 和 Martin Hellman 的名字命名。Diffie-Hellman 算法的安全性取决于在一个有限字段中计算离散算法的困难。
    单向散列算法
    散列,也称为散列值或消息摘要 ,是一种与基于密钥(对称密钥或公钥)的加密不同的数据转换类型。散列就是通过把一个叫做散列算法的单向数学函数应用于数据,将任意长度的一块数据转换为一个定长的、不可逆转的数字,其长度通常在128~256位之间。所产生的散列值的长度应足够长,因此使找到两块具有相同散列值的数据的机会很少。如发件人生成邮件的散列值并加密它,然后将它与邮件本身一起发送。而收件人同时解密邮件和散列值,并由接收到的邮件产生另外一个散列值,然后将两个散列值进行比较。如果两者相同,邮件极有可能在传输期间没有发生任何改变。

    下面是几个常用的散列函数:

    MD5:是RSA数据安全公司开发的一种单向散列算法,MD5被广泛使用,可以用来把不同长度的数据块进行暗码运算成一个128位的数值。
    SHA-1:与 DSA 公钥算法相似,安全散列算法1(SHA-1)也是由 NSA 设计的,并由 NIST 将其收录到 FIPS 中,作为散列数据的标准。它可产生一个 160 位的散列值。SHA-1 是流行的用于创建数字签名的单向散列算法。
    MAC(Message Authentication Code):消息认证代码,是一种使用密钥的单向函数,可以用它们在系统上或用户之间认证文件或消息,常见的是HMAC(用于消息认证的密钥散列算法)。
    CRC(Cyclic Redundancy Check):循环冗余校验码,CRC校验由于实现简单,检错能力强,被广泛使用在各种数据校验应用中。占用系统资源少,用软硬件均能实现,是进行数据传输差错检测地一种很好的手段(CRC 并不是严格意义上的散列算法,但它的作用与散列算法大致相同,所以归于此类)。
    数字签名:结合使用公钥与散列算法
    数字签名是邮件、文件或其它数字编码信息的发件人将他们的身份与信息绑定在一起(即为信息提供签名)的方法。对信息进行数字签名的过程,需要将信息与由发件人掌握的秘密信息一起转换(使用私钥)为叫做签名的标记。数字签名用于公钥环境(任何人都可以拥有)中,它通过验证发件人确实是他或她所声明的那个人,并确认收到的邮件与发送的邮件完全相同。

    散列算法处理数据的速度比公钥算法快得多。散列数据还缩短了要签名的数据的长度,因而加快了签名过程。

    密钥交换:结合使用对称密钥与公钥
    对称密钥算法非常适合于快速并安全地加密数据。但其缺点是,发件人和收件人必须在交换数据之前先交换机密密钥。结合使用加密数据的对称密钥算法与交换机密密钥的公钥算法可产生一种既快速又灵活的解决方案。

    支持一下
    扫一扫,支持forsigner
    • 微信扫一扫
    • 支付宝扫一扫