rfc:tls-peer-verification
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
rfc:tls-peer-verification [2013/10/15 17:47] – created rdlowrey | rfc:tls-peer-verification [2017/09/22 13:28] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== TLS Peer Verification ====== | ====== TLS Peer Verification ====== | ||
- | * Version: 0.1 | + | * Version: 0.2 |
* Date: 2013-10-15 | * Date: 2013-10-15 | ||
* Author: Daniel Lowrey, rdlowrey@gmail.com | * Author: Daniel Lowrey, rdlowrey@gmail.com | ||
- | * Status: | + | * Status: |
- | * First Published at: http:// | + | * First Published at: http:// |
+ | * Major Revision (v0.1 -> v0.2): 2013-12-17 | ||
===== Introduction ===== | ===== Introduction ===== | ||
Line 14: | Line 15: | ||
The most basic requirement for secure communication is to first establish that you are actually | The most basic requirement for secure communication is to first establish that you are actually | ||
- | communicating directly with the intended party. Absent this assurance all the encryption in the world | + | communicating directly with the intended party (without unwanted intermediaries). Absent this |
- | won't afford adequate security. Regrettably, | + | assurance all the encryption in the world won't afford adequate security. Regrettably, |
- | requirement. Although choosing //not// to verify peers makes it exceedingly simple to access encrypted | + | existing SSL/TLS stream wrappers fail this requirement. Although choosing //not// to verify |
- | resources, it also leaves many (most?) encrypted userland communications open to Man-in-the-Middle (MitM) | + | peers makes it exceedingly simple to access encrypted resources, it also leaves many (most?) |
- | attacks: | + | encrypted userland communications open to Man-in-the-Middle (MitM) attacks: |
<code php> | <code php> | ||
Line 55: | Line 56: | ||
* Global CA defaults may be specified via new '' | * Global CA defaults may be specified via new '' | ||
* Per-stream CA paths may still be specified at call time by passing the existing '' | * Per-stream CA paths may still be specified at call time by passing the existing '' | ||
- | | + | |
+ | //NEW ADDITIONS:// | ||
+ | |||
+ | | ||
+ | * Only if the OpenSSL defaults cannot be loaded and no manual user assignments exist via the .ini directives or stream context options is an '' | ||
+ | |||
+ | ===== Differences From the Original Proposal ===== | ||
+ | |||
+ | The first iteration of the RFC did not take advantage of the compiled OpenSSL lib's CA defaults. This change | ||
+ | |||
+ | Notes on this change: | ||
+ | |||
+ | * OpenSSL does NOT include any CA files or hashed directories as part of its distribution. | ||
+ | * Distros use their own values when compiling OpenSSL to manually | ||
+ | * Because the defaults are specified when the OpenSSL lib is compiled users building ext/openssl against manually-compiled OpenSSL libs will need to either: specify the CA defaults when compiling the lib, manually place PEM-formatted versions of the necessary files in the appropriate directory or specify a location via the new .ini directives to enjoy the benefits of distro-managed CA files. | ||
+ | * Users may check the default CA file location of their OpenSSL binary using the '' | ||
===== Usage Examples ===== | ===== Usage Examples ===== | ||
+ | |||
+ | Distro defaults prevent most BC-breakage: | ||
+ | |||
+ | <code php> | ||
+ | <?php | ||
+ | // Look 'ma, no BC-breaks! | ||
+ | $html = file_get_contents(' | ||
+ | </ | ||
Specifying a global CA file via '' | Specifying a global CA file via '' | ||
Line 105: | Line 129: | ||
===== Backward Incompatible Changes ===== | ===== Backward Incompatible Changes ===== | ||
- | With the specification of the '' | + | Most preexisting code is expected work without any BC implications |
- | without any BC implications | + | |
- | will see existing usages that do not explicitly enable/ | + | |
- | '' | + | |
===== Proposed PHP Version ===== | ===== Proposed PHP Version ===== | ||
Line 127: | Line 148: | ||
The biggest impediment to secure peer verification is the lack of a CA file for name verification. | The biggest impediment to secure peer verification is the lack of a CA file for name verification. | ||
By exposing a php.ini directive specifying a global CA file users/ | By exposing a php.ini directive specifying a global CA file users/ | ||
- | for stream contexts to achieve secure peer verification. | + | for stream contexts to achieve secure peer verification. |
- | it's possible to bundle a CA file with the PHP distribution and default to secure settings | + | the process of specifying CA files in custom environments. This value should be left empty when using |
- | without breaking BC. An example of this kind of file is the [[http:// | + | distros that supply a PHP version built against their own pre-compiled OpenSSL lib. Essentially, |
- | (by way of mozilla.org). | + | this directive |
+ | specify a value for this directive then the answer is very likely, "No." | ||
* '' | * '' | ||
Line 137: | Line 159: | ||
their own custom hashed certificate directory path on each encrypted stream connection. The directive | their own custom hashed certificate directory path on each encrypted stream connection. The directive | ||
exists solely as a convenience for these users and as such can safely be left empty or unspecified both | exists solely as a convenience for these users and as such can safely be left empty or unspecified both | ||
- | in development and production environments. Its use corresponds to the ''" | + | in development and production environments. Its use corresponds to the ''" |
+ | option | ||
+ | this directive then the answer is very likely, " | ||
===== Unaffected PHP Functionality ===== | ===== Unaffected PHP Functionality ===== | ||
Line 147: | Line 171: | ||
===== Open Issues ===== | ===== Open Issues ===== | ||
- | * Should PHP bundle a default CA File with the distribution? | + | None. |
===== Proposed Voting Choices ===== | ===== Proposed Voting Choices ===== | ||
* Should secure-by-default client peer verification be implemented for 5.6? | * Should secure-by-default client peer verification be implemented for 5.6? | ||
- | * If secure-by-default verification is implemented, | ||
- | ===== Patches and Tests ===== | + | ===== Implementation |
- | The patch linked below is intended as final (subject to any changes instigated during the RFC process). There are still a couple of failing openssl tests that are broken by the change to default | + | * https:// |
- | verification. These will be amended soon. | + | |
- | * https:// | + | ===== References ===== |
- | ===== Implementation ===== | + | * [[http:// |
- | TBD | + | ===== Vote ===== |
- | ===== References ===== | + | // The initial vote was halted to clarify voting options and improve the implementation. Please read the updated section titled " |
+ | |||
+ | Voting closes Dec. 31 ... happy holidays! | ||
- | * [[http:// | + | <doodle title=" |
+ | * Yes | ||
+ | * No | ||
+ | </doodle> | ||
===== Rejected Features ===== | ===== Rejected Features ===== | ||
- | TBD | + | The original vote offered an option to maintain a CA file as part of the PHP distribution. This option was discarded with the introduction of distro-managed CA stores as part of the implementation. |
rfc/tls-peer-verification.1381859274.txt.gz · Last modified: 2017/09/22 13:28 (external edit)