5 SSL的安全
5.1 介绍
5.2 SSL都提供了什么
ssl提供通道级别的安全 连接的两端知道所传输的数据是保密的 而且没有被篡改 对服务器端的认证是必需的 客户端认证可选 针对例外情况的安全通知功能其中包括错误警示和连接关闭
所有这些保护都依赖于某些对系统的假定 我们假定已经正确产生了密钥资料而且被安全的保管着 若没有晋升的遵循某些步骤就会使安全大打折扣
5.3 保护master_secret
几乎协议的所有安全都依赖于master_secreted 保密
5.4 保护服务器的私用密钥
一种可以让攻击者获得master_secret的显而易见的方法就是取得服务器的私用密钥
5.5 使用良好的随机性
5.6 检查证书链
5.7 算法的选择
5.8 小结
9 Ssl上的http
9.1 介绍
http是第一个使用ssl的协议 https 和 http Upgrade
9.2 保护web的安全
电子商务需要的安全性能 用户需要确信其客户端连接的是正确的服务器
基本技术
http
html
url
现实的web环境还有几项功能还无法从到目前为止我们所提出的简单的客户/服务器模型中显露出来的 在我们考虑web安全问题的时候 这三种功能实际上有着特殊的关系 他们是 连接行为 代理 和 虚拟主机
成功的web安全解决方案必须能够通过代理进行数据传输
9.3 http
http是一种简单的协议 交互的基本单位是请求/响应对 客户端打开一条到服务器的tcp连接并将请求发送出去。而服务器将相应发回 服务器使用表示长度的头信息 或仅仅通过关闭连接来指示相应的结尾
请求
三个部分 请求信息行 头信息 可选的信息体
响应
状态行 头信息 可选的信息体
9.4 html
使用一系列给文档增加结构的标记来修饰的ascii文本
锚点
插图
表单
动态内容
9.5 url
统一资源定位符
9.6 http的连接行为
9.7 代理
缓存代理 防火墙代理
9.8 虚拟主机
9.9 协议选择
ssl背后的设计思想就是你可以简单的将套接字调用替换为ssl而别的代码一点都不用动
独立端口方案
9.10 客户端认证
基于证书的客户端认证对web应用来说并不是一种优先选择的措施 web站点通常选择使用外部的身份认证措施
让服务器在引用中指明它期望客户端认证 这样就能够允许客户端在握手中予以提供
9.11 引用完整性
使用url来提供引用完整性
9.12 https
rfc 2818
9.13 https概述
独立端口（443）策略用于http nntp smtp
客户端连接到服务器 磋商一条ssl连接 然后再ssl应用数据通道上传输它的http数据
9.14 url与引用完整性
降级攻击
端点认证
失败行为
依照用户的选择
引用源
客户端身份
9.15 连接关闭
会话恢复
错误处理
截断攻击
9.16 代理
9.17 虚拟主机
9.18 客户端认证
9.19 Referer
9.20 替换攻击
9.21 升级
9.22 编程问题
9.23 代理connect
9.24 处理多个客户端
9.25 总结
10 Tls 扩展
1
提供了扩展hello message 的方法
扩展信息可以提供
1〉 允许client 提供他所需要的serve的名字
2〉 允许client 和server 协商最大传输片断（对于有内存限制的client 和一些有网络带宽限制的访问有用）
3〉 可以让server和client 协商 client certificate urls 用于验证用户 同时可以节省客户端的内存
4〉 客户端可以向server 出示他的ca root ??? 这个功能不是很清晰
5〉 允许client 和server 使用缩短的mac 以节省带宽
6〉 允许协商server 在handshake阶段是否向client 发送client certificate status information
向下兼容
2
2.1. Extended Client Hello
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>;
Extension client_hello_extension_list<0..2^16-1>; 扩展属性链
} ClientHello;
扩展的ClientHello结构
在tls协议里允许clienthell信息里面添加更多的信息 所以扩展的clienthello并没有违反原来的tls协议规范
2.2 Extend Server Hello
struct {
ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;
Extension server_hello_extension_list<0..2^16-1>;
} ServerHello; 只在收到了带扩展选项的clienthello时候才会发出 否则可能会破坏当前连接
2.3 Hello Extensions
struct {
ExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} Extension;
enum {
server_name(0), max_fragment_length(1),
client_certificate_url(2), trusted_ca_keys(3),
truncated_hmac(4), status_request(5), (65535)
} ExtensionType;
其余的几个协议就是在此基础上发展起来的
2.4 对于Handshake protocol 的扩展
enum {
hello_request(0), client_hello(1), server_hello(2),
certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16),
finished(20), certificate_url(21), certificate_status(22),
(255)
} HandshakeType;
Certificate_url / Certificate_status 新添的两种属性
struct {
HandshakeType msg_type; /* handshake type */
uint24 length; /* bytes in message */
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case certificate: Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done: ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
case certificate_url: CertificateURL;
case certificate_status: CertificateStatus;
} body;
} Handshake;
3 第三节最重要 对每一个扩展属性都要仔细解释
3.1. Server Name Indication
3.2. Maximum Fragment Length Negotiation
3.3. Client Certificate URLs
3.4. Trusted CA Indication
3.5. Truncated HMAC
3.6. Certificate Status Request
六种结构
11 TLS 上面向连接的媒体传输
1. Overview
1.1 SDP Operational Modes
两种行为模式
一 server publish a SDP session description describing a multimedia session it is making
available. SAP 周期的向一个知名的组播组组播SDP session (单播也可以)
二 也可以采用 offer answer 模式 这种方式 允许双方的协商 （SIP）
1.2 Threat Model
描述攻击者怎样威胁multimedia session 以及 怎样用tls防范
a> 窃听 几乎所有tls操作都可以防范此类攻击 保持数据保密性
b> 在连接中的数据 ？？
c> 修改和重定向 session descriptions ？？
1.3 The Need For Self-Signed Certificates
SDP session descriptions are created by any endpoint that needs to
participate in a multimedia session.
单方面请求的 ？？
certificate fingerprint 当作 SDP session的一个属性 用作双方认证
此时lf-signed Certificate 不能确定是安全的
1.4 Example SDP Description For TLS Connection
m=image 54111 TCP/TLS t38
c=IN IP4 192.0.2.2
a=setup:passive
a=connection:new
a=fingerprint:SHA-1 /
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
Figure 1: Example SDP Description Offering a TLS Media Stream
an SDP offer which signals the availability of a T.38 fax session over TLS.
2 . Protocol Identifiers
m=image 54111 TCP/TLS t38
3 . Fingerprint Attribute
In order to associate media streams with connections, and to prevent
unauthorized barge-in attacks on the media streams, endpoints MUST
provide a certificate fingerprint. If the X.509 certificate
presented for the TLS connection matches the fingerprint presented in
the SDP, the endpoint can be confident that the author of the SDP is
indeed the initiator of the connection.
A certificate fingerprint is a secure one-way hash of the DER
(distinguished encoding rules) form of the certificate. (Certificate
fingerprints are widely supported by tools which manipulate X.509
certificates; for instance, the command "openssl x509 -fingerprint"
causes the command-line tool of the openssl package to print a
certificate fingerprint, and the certificate managers for Mozilla and
Internet Explorer display them when viewing the details of a
certificate.)
A fingerprint is represented in SDP as an attribute (an 'a' line).
It consists of the name of the hash function used, followed by the
hash value itself. The hash value is represented as a sequence of
upper-case hexadecimal bytes, separated by colons. The number of
bytes is defined by the hash function. (This is the syntax used by
openssl and by the browsers' certificate managers. It is different
from the syntax used to represent hash values in, e.g., HTTP digest
authentication [18], which uses unseparated lower-case hexadecimal
bytes. It was felt that consistency with other applications of
fingerprints was more important.)
The formal syntax of the fingerprint attribute is given in Augmented
Backus-Naur Form [10] in Figure 2. This syntax extends the BNF
syntax of SDP [1].
attribute =/ fingerprint-attribute
fingerprint-attribute = "fingerprint" ":" hash-func SP fingerprint
hash-func = "sha-1" / "sha-224" / "sha-256" /
"sha-384" / "sha-512" /
"md5" / "md2" / token
; Additional hash functions can only come
; from updates to RFC 3279
fingerprint = 2UHEX *(":" 2UHEX)
; Each byte in upper-case hex, separated
; by colons.
UHEX = DIGIT / %x41-46 ; A-F uppercase
Figure 2: Augmented Backus-Naur Syntax for the Fingerprint Attribute
A certificate fingerprint MUST be computed using the same one-way
hash function as is used in the certificate's signature algorithm.
(This guarantees that the fingerprint will be usable by the other
endpoint, so long as the certificate itself is.) Following RFC 3279
[7] as updated by RFC 4055 [9], therefore, the defined hash functions
are 'SHA-1' [11] [19], 'SHA-224' [11], 'SHA-256' [11], 'SHA-384'
[11], 'SHA-512' [11], 'MD5' [12], and 'MD2' [13], with 'SHA-1'
preferred. Additional hash functions can be defined only by
standards-track RFCs which update or obsolete RFC 3279 [7]. Self-
signed certificates (for which legacy certificates are not a
consideration) MUST use one of the FIPS 180 algorithms (SHA-1, SHA-
224, SHA-256, SHA-384, or SHA-512) as their signature algorithm, and
thus also MUST use it to calculate certificate fingerprints.
The fingerprint attribute may be either a session-level or a media-
level SDP attribute. If it is a session-level attribute, it applies
to all TLS sessions for which no media-level fingerprint attribute is
defined.
4. Endpoint Identification
4.1 Certificate Choice
X.509 certificates certify identities. The certificate provided for
a TLS connection needs to certify an appropriate identity for the
connection. Identity matching is performed using the matching rules
specified by RFC 3280 [8]. If more than one identity of a given type
is present in the certificate (e.g., more than one dNSName name), a
match in any one of the set is considered acceptable.
The certificate presented by an endpoint MUST correspond to one of
the following identities:
o If the connection address for the media description is specified
as an IP address, the endpoint MAY use a certificate with an
iPAddress subjectAltName which exactly matches the IP in the
connection-address in the session description's 'c' line.
o If the connection address for the media description is specified
as a fully-qualified domain name, the endpoint MAY use a
certificate with a dNSName subjectAltName matching the specified
'c' line connection-address exactly. (Wildcard patterns MUST NOT
be used.)
o If the SDP session description describing the session was
transmitted over a protocol (such as SIP [16]) for which the
identities of session participants are defined by uniform resource
identifiers (URIs), the endpoint MAY use a certificate with a
uniformResourceIdentifier subjectAltName. The details of what
URIs are appropriate are dependent on the transmitting protocol.
(For more details on this, see Section 7.)
If the SDP session description describing the session was transmitted
over an end-to-end secure protocol which uses X.509 certificates, and
the certificates sent fulfill the requirements above (as they
normally would be expected to), the endpoint MAY use the same
certificate to certify the media connection. For example, an SDP
description sent over HTTP/TLS [20] or secured by S/MIME [17] MAY use
the same certificate to secure the media connection. (Note, however,
that the sips protocol [16] (SIP over TLS) provides only hop-by-hop
security, so its TLS certificates do not satisfy this criterion.) To
support the use of certificate caches, as described in Section 7,
endpoints SHOULD consistently provide the same certificate for each
identity they support.
4.2 Certificate Presentation
In all cases, an endpoint acting as the TLS server, i.e., one taking
the 'setup:passive' role, in the terminology of connection-oriented
media, MUST present a certificate during TLS initiation, following
the rules presented in Section 6.1. If the certificate does not
match the original fingerprint, or, if there is no fingerprint, the
certificate identity is incorrect, the client endpoint MUST either
notify the user, if possible, or terminate the media connection with
a bad certificate error.
If the SDP offer/answer model [5] is being used, the client (the
endpoint with the 'setup:active' role) MUST also present a
certificate following the rules of Section 6.1. The server MUST
request a certificate, and if the client does not provide one, if the
certificate does not match the provided fingerprint, or, if there was
no fingerprint, the certificate identity is incorrect, the server
endpoint MUST either notify the user or terminate the media
connection with a bad certificate error.
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in the Connection-Oriented Media
specification [2]) begin listening for an incoming connection as soon
as it sends its offer. However, because its peer's media connection
may outrace its answer, it MUST NOT definitively accept the peer's
certificate until it has received and processed the SDP answer.
If offer/answer is not being used (e.g., if the SDP was sent over the
Session Announcement Protocol [15]), the TLS server typically has no
external knowledge of what the TLS client's identity ought to be. In
this case, no client certificate need be presented, and no
certificate validation can be performed, unless the server has
knowledge of valid clients through some external means.
12 tls的预共享密码加密套件
Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)
12.1 Introduction
tls通常用public key certificates 或者 Kerberos 认证 本章介绍tls如何运用psk （在两个通信实体间事先共享的密钥）建立tls连接
a> 避免了交换证书的操作节省资源
b> 从密钥管理的角度考虑 更方便与证书操作相比
CipherSuite Key Exchange Cipher Hash
TLS_PSK_WITH_RC4_128_SHA PSK RC4_128 SHA
TLS_PSK_WITH_3DES_EDE_CBC_SHA PSK 3DES_EDE_CBC SHA
TLS_PSK_WITH_AES_128_CBC_SHA PSK AES_128_CBC SHA
TLS_PSK_WITH_AES_256_CBC_SHA PSK AES_256_CBC SHA
TLS_DHE_PSK_WITH_RC4_128_SHA DHE_PSK RC4_128 SHA
TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA DHE_PSK 3DES_EDE_CBC SHA
TLS_DHE_PSK_WITH_AES_128_CBC_SHA DHE_PSK AES_128_CBC SHA
TLS_DHE_PSK_WITH_AES_256_CBC_SHA DHE_PSK AES_256_CBC SHA
TLS_RSA_PSK_WITH_RC4_128_SHA RSA_PSK RC4_128 SHA
TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA RSA_PSK 3DES_EDE_CBC SHA
TLS_RSA_PSK_WITH_AES_128_CBC_SHA RSA_PSK AES_128_CBC SHA
TLS_RSA_PSK_WITH_AES_256_CBC_SHA RSA_PSK AES_256_CBC SHA
以上一些加密套件运用了新的密钥交换算法重用了原来的加密和mac算法
12.1.1 Applicability Statement
另一种可考虑的方案 是利用自签名的证书同时带有公钥的水印
也可以用srp secure remote password 套件用于认证
srp被设计为与密码协同工作 同时阻止密码攻击 但是比psk造价昂贵
12.1.2 Conventions Used in This Document
must may ….
12.2 PSK Key Exchange Algorithm
本节定义了psk密钥交换算法 和相应的加密套件 这些套件只用对称密钥算法（use only symmetric key algorithms）
The elements in parenthesis are not included
when the PSK key exchange algorithm is used, and "*" indicates a
situation-dependent message that is not always sent.
Client Server
------ ------
ClientHello -------->
ServerHello
(Certificate)
ServerKeyExchange*
(CertificateRequest)
<-------- ServerHelloDone
(Certificate)
ClientKeyExchange
(CertificateVerify)
ChangeCipherSpec
Finished -------->
ChangeCipherSpec
<-------- Finished
Application Data <-------> Application Data
The client indicates its willingness to use pre-shared key
authentication by including one or more PSK ciphersuites in the
ClientHello message. If the TLS server also wants to use pre-shared
keys, it selects one of the PSK ciphersuites, places the selected
ciphersuite in the ServerHello message, and includes an appropriate
ServerKeyExchange message (see below). The Certificate and
CertificateRequest payloads are omitted from the response.
Both clients and servers may have pre-shared keys with several
different parties. The client indicates which key to use by
including a "PSK identity" in the ClientKeyExchange message (note
that unlike in [SHAREDKEYS], the session_id field in ClientHello
message keeps its usual meaning). To help the client in selecting
which identity to use, the server can provide a "PSK identity hint"
in the ServerKeyExchange message. If no hint is provided, the
ServerKeyExchange message is omitted. See Section 5 for a more
detailed description of these fields.
The format of the ServerKeyExchange and ClientKeyExchange messages is
shown below.
struct {
select (KeyExchangeAlgorithm) {
/* other cases for rsa, diffie_hellman, etc. */
case psk: /* NEW */
opaque psk_identity_hint<0..2^16-1>;
};
} ServerKeyExchange;
struct {
select (KeyExchangeAlgorithm) {
/* other cases for rsa, diffie_hellman, etc. */
case psk: /* NEW */
opaque psk_identity<0..2^16-1>;
} exchange_keys;
} ClientKeyExchange;
The premaster secret is formed as follows: if the PSK is N octets
long, concatenate a uint16 with the value N, N zero octets, a second
uint16 with the value N, and the PSK itself.
Note 1: All the ciphersuites in this document share the same
general structure for the premaster secret, namely,
struct {
opaque other_secret<0..2^16-1>;
opaque psk<0..2^16-1>;
};
Here "other_secret" either is zeroes (plain PSK case) or comes
from the Diffie-Hellman or RSA exchange (DHE_PSK and RSA_PSK,
respectively). See Sections 3 and 4 for a more detailed
description.
Note 2: Using zeroes for "other_secret" effectively means that
only the HMAC-SHA1 part (but not the HMAC-MD5 part) of the TLS PRF
is used when constructing the master secret. This was considered
more elegant from an analytical viewpoint than, for instance,
using the same key for both the HMAC-MD5 and HMAC-SHA1 parts. See
[KRAWCZYK] for a more detailed rationale.
The TLS handshake is authenticated using the Finished messages as
usual.
If the server does not recognize the PSK identity, it MAY respond
with an "unknown_psk_identity" alert message. Alternatively, if the
server wishes to hide the fact that the PSK identity was not known,
it MAY continue the protocol as if the PSK identity existed but the
key was incorrect: that is, respond with a "decrypt_error" alert.
12.3 DHE_PSK Key Exchange Algorithm
This section defines additional ciphersuites that use a PSK to
authenticate a Diffie-Hellman exchange. These ciphersuites give some
additional protection against dictionary attacks and also provide
Perfect Forward Secrecy (PFS). See Section 7 for discussion of
related security considerations.
When these ciphersuites are used, the ServerKeyExchange and
ClientKeyExchange messages also include the Diffie-Hellman
parameters. The PSK identity and identity hint fields have the same
meaning as in the previous section (note that the ServerKeyExchange
message is always sent, even if no PSK identity hint is provided).
The format of the ServerKeyExchange and ClientKeyExchange messages is
shown below.
struct {
select (KeyExchangeAlgorithm) {
/* other cases for rsa, diffie_hellman, etc. */
case diffie_hellman_psk: /* NEW */
opaque psk_identity_hint<0..2^16-1>;
ServerDHParams params;
};
} ServerKeyExchange;
struct {
select (KeyExchangeAlgorithm) {
/* other cases for rsa, diffie_hellman, etc. */
case diffie_hellman_psk: /* NEW */
opaque psk_identity<0..2^16-1>;
ClientDiffieHellmanPublic public;
} exchange_keys;
} ClientKeyExchange;
The premaster secret is formed as follows. First, perform the
Diffie-Hellman computation in the same way as for other
Diffie-Hellman-based ciphersuites in [TLS]. Let Z be the value
produced by this computation (with leading zero bytes stripped as in
other Diffie-Hellman-based ciphersuites). Concatenate a uint16
containing the length of Z (in octets), Z itself, a uint16 containing
the length of the PSK (in octets), and the PSK itself.
This corresponds to the general structure for the premaster secrets
(see Note 1 in Section 2) in this document, with "other_secret"
containing Z.
12.4 RSA_PSK Key Exchange Algorithm
The ciphersuites in this section use RSA and certificates to
authenticate the server, in addition to using a PSK.
As in normal RSA ciphersuites, the server must send a Certificate
message. The format of the ServerKeyExchange and ClientKeyExchange
messages is shown below. If no PSK identity hint is provided, the
ServerKeyExchange message is omitted.
struct {
select (KeyExchangeAlgorithm) {
/* other cases for rsa, diffie_hellman, etc. */
case rsa_psk: /* NEW */
opaque psk_identity_hint<0..2^16-1>;
};
} ServerKeyExchange;
struct {
select (KeyExchangeAlgorithm) {
/* other cases for rsa, diffie_hellman, etc. */
case rsa_psk: /* NEW */
opaque psk_identity<0..2^16-1>;
EncryptedPreMasterSecret;
} exchange_keys;
} ClientKeyExchange;
The EncryptedPreMasterSecret field sent from the client to the server
contains a 2-byte version number and a 46-byte random value,
encrypted using the server's RSA public key as described in Section
7.4.7.1 of [TLS]. The actual premaster secret is formed by both
parties as follows: concatenate a uint16 with the value 48, the
2-byte version number and the 46-byte random value, a uint16
containing the length of the PSK (in octets), and the PSK itself.
(The premaster secret is thus 52 octets longer than the PSK.)
This corresponds to the general structure for the premaster secrets
(see Note 1 in Section 2) in this document, with "other_secret"
containing both the 2-byte version number and the 46-byte random
value.
Neither the normal RSA ciphersuites nor these RSA_PSK ciphersuites
themselves specify what the certificates contain (in addition to the
RSA public key), or how the certificates are to be validated. In
particular, it is possible to use the RSA_PSK ciphersuites with
unvalidated self-signed certificates to provide somewhat similar
protection against dictionary attacks, as the DHE_PSK ciphersuites
define in Section 3.
12.5 Conformance Requirements
12.5.1 PSK Identity Encoding
12.5.2 Identity Hint
12.5.3 Requirements for TLS Implementations
12.5.4 Requirements for Management Interfaces
12.6 Security Considerations
12.6.1 Perfect Forward Secrecy (PFS)
12.6.2 Brute-Force and Dictionary Attacks
12.6.3 Identity Privacy
12.6.4 Implementation Notes
openssl 代码分析
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
