- 04 11月, 2016 1 次提交
-
-
由 Matt Caswell 提交于
Writing still to be done Reviewed-by: NRich Salz <rsalz@openssl.org>
-
- 02 11月, 2016 1 次提交
-
-
由 Matt Caswell 提交于
Includes addition of the various options to s_server/s_client. Also adds one of the new TLS1.3 ciphersuites. This isn't "real" TLS1.3!! It's identical to TLS1.2 apart from the protocol and the ciphersuite...and the ciphersuite is just a renamed TLS1.2 one (not a "real" TLS1.3 ciphersuite). Reviewed-by: NRich Salz <rsalz@openssl.org>
-
- 03 10月, 2016 8 次提交
-
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Matt Caswell 提交于
We now set the handshake header, and close the packet directly in the write_state_machine. This is now possible because it is common for all messages. Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Matt Caswell 提交于
tls_construct_finished() used to have different arguments to all of the other construction functions. It doesn't anymore, so there is no neeed to treat it as a special case. Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Matt Caswell 提交于
Ensure all message types work the same way including CCS so that the state machine doesn't need to know about special cases. Put all the special logic into ssl_set_handshake_header() and ssl_close_construct_packet(). Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Matt Caswell 提交于
Move setting the handshake header up a level into the state machine code in order to reduce boilerplate. Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Matt Caswell 提交于
Instead of initialising, finishing and cleaning up the WPACKET in every message construction function, we should do it once in write_state_machine(). Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Matt Caswell 提交于
ssl_set_handshake_header2() was only ever a temporary name while we had to have ssl_set_handshake_header() for code that hadn't been converted to WPACKET yet. No code remains that needed that so we can rename it. Reviewed-by: NRich Salz <rsalz@openssl.org>
-
- 02 10月, 2016 1 次提交
-
-
由 Dr. Stephen Henson 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
- 30 9月, 2016 3 次提交
-
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
- 29 9月, 2016 8 次提交
-
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Matt Caswell 提交于
In plain PSK we don't need to do anymore construction after the preamble. We weren't detecting this case and treating it as an unknown cipher. Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Matt Caswell 提交于
Merge declarations of same type together. Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
- 28 9月, 2016 1 次提交
-
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
- 26 9月, 2016 2 次提交
-
-
由 Matt Caswell 提交于
commit c536b6be introduced a bug that causes a reachable assert. This fixes it. Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Matt Caswell 提交于
The buffer to receive messages is initialised to 16k. If a message is received that is larger than that then the buffer is "realloc'd". This can cause the location of the underlying buffer to change. Anything that is referring to the old location will be referring to free'd data. In the recent commit c1ef7c97 (master) and 4b390b6c (1.1.0) the point in the code where the message buffer is grown was changed. However s->init_msg was not updated to point at the new location. CVE-2016-6309 Reviewed-by: NEmilia Käsper <emilia@openssl.org>
-
- 23 9月, 2016 1 次提交
-
-
由 Matt Caswell 提交于
We actually construct a HelloVerifyRequest in two places with common code pulled into a single function. This one commit handles both places. Reviewed-by: NRich Salz <rsalz@openssl.org>
-
- 22 9月, 2016 5 次提交
-
-
由 Rich Salz 提交于
Change code so when switching on an enumeration, have case's for all enumeration values. Reviewed-by: NAndy Polyakov <appro@openssl.org>
-
由 Dmitry Belyavsky 提交于
Russian GOST ciphersuites are vulnerable to the KCI attack because they use long-term keys to establish the connection when ssl client authorization is on. This change brings the GOST implementation into line with the latest specs in order to avoid the attack. It should not break backwards compatibility. Reviewed-by: NRich Salz <rsalz@openssl.org> Reviewed-by: NMatt Caswell <matt@openssl.org>
-
由 Richard Levitte 提交于
Reviewed-by: NMatt Caswell <matt@openssl.org>
-
由 Matt Caswell 提交于
This issue is very similar to CVE-2016-6307 described in the previous commit. The underlying defect is different but the security analysis and impacts are the same except that it impacts DTLS. A DTLS message includes 3 bytes for its length in the header for the message. This would allow for messages up to 16Mb in length. Messages of this length are excessive and OpenSSL includes a check to ensure that a peer is sending reasonably sized messages in order to avoid too much memory being consumed to service a connection. A flaw in the logic of version 1.1.0 means that memory for the message is allocated too early, prior to the excessive message length check. Due to way memory is allocated in OpenSSL this could mean an attacker could force up to 21Mb to be allocated to service a connection. This could lead to a Denial of Service through memory exhaustion. However, the excessive message length check still takes place, and this would cause the connection to immediately fail. Assuming that the application calls SSL_free() on the failed conneciton in a timely manner then the 21Mb of allocated memory will then be immediately freed again. Therefore the excessive memory allocation will be transitory in nature. This then means that there is only a security impact if: 1) The application does not call SSL_free() in a timely manner in the event that the connection fails or 2) The application is working in a constrained environment where there is very little free memory or 3) The attacker initiates multiple connection attempts such that there are multiple connections in a state where memory has been allocated for the connection; SSL_free() has not yet been called; and there is insufficient memory to service the multiple requests. Except in the instance of (1) above any Denial Of Service is likely to be transitory because as soon as the connection fails the memory is subsequently freed again in the SSL_free() call. However there is an increased risk during this period of application crashes due to the lack of memory - which would then mean a more serious Denial of Service. This issue does not affect TLS users. Issue was reported by Shi Lei (Gear Team, Qihoo 360 Inc.). CVE-2016-6308 Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
由 Matt Caswell 提交于
A TLS message includes 3 bytes for its length in the header for the message. This would allow for messages up to 16Mb in length. Messages of this length are excessive and OpenSSL includes a check to ensure that a peer is sending reasonably sized messages in order to avoid too much memory being consumed to service a connection. A flaw in the logic of version 1.1.0 means that memory for the message is allocated too early, prior to the excessive message length check. Due to way memory is allocated in OpenSSL this could mean an attacker could force up to 21Mb to be allocated to service a connection. This could lead to a Denial of Service through memory exhaustion. However, the excessive message length check still takes place, and this would cause the connection to immediately fail. Assuming that the application calls SSL_free() on the failed conneciton in a timely manner then the 21Mb of allocated memory will then be immediately freed again. Therefore the excessive memory allocation will be transitory in nature. This then means that there is only a security impact if: 1) The application does not call SSL_free() in a timely manner in the event that the connection fails or 2) The application is working in a constrained environment where there is very little free memory or 3) The attacker initiates multiple connection attempts such that there are multiple connections in a state where memory has been allocated for the connection; SSL_free() has not yet been called; and there is insufficient memory to service the multiple requests. Except in the instance of (1) above any Denial Of Service is likely to be transitory because as soon as the connection fails the memory is subsequently freed again in the SSL_free() call. However there is an increased risk during this period of application crashes due to the lack of memory - which would then mean a more serious Denial of Service. This issue does not affect DTLS users. Issue was reported by Shi Lei (Gear Team, Qihoo 360 Inc.). CVE-2016-6307 Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
- 21 9月, 2016 2 次提交
-
-
由 Matt Caswell 提交于
Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
由 Richard Levitte 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
- 20 9月, 2016 7 次提交
-
-
由 Matt Caswell 提交于
All the other functions that take an argument for the number of bytes use convenience macros for this purpose. We should do the same with WPACKET_put_bytes(). Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-
由 Matt Caswell 提交于
Reviewed-by: NRich Salz <rsalz@openssl.org>
-