LIBRELAMPSERVER STACK DOCUMENTATION
A publication of Pipfrosch Press
Alice Wonder (Editor and Author Pseudonym)
May 27, 2019 Legal Stuff
The instructions in this document and the software packages referred to provided AS IS NO WAR- RANTY WITH NO GUARANTEE OF FITNESS FOR USE. Use at your own risk, but I AM NOT LIABLE FOR ANY DAMAGE THAT RESULTS. That being said, if you do encounter a problem, please contact me and if I have the time, I may be able to help resolve the issue. No guarantees though. With the exception of the licenses that are included in Part III (page 38) and the UNIX man pages that are included in PartIV (page 74), this documentation is released under the terms of the GNU Free Document License (FDL) version 1.3.
© 2019 Michael A. Peters Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and one Back-Cover Text:
“Extensive amounts of blood, sweat, tears, and time went into the authoring of this manual. The author as of 2019 is living well below the poverty line. Please consider a financial contribution at https://www.paypal.me/pipfrosch.” (see page 112)
A copy of the license is included in the section entitled “GNU Free Documentation License” on page 38.
The man pages in PartIV have authorship and license information included at the end of each man page that is included. 1 The LATEX source files for this document are maintained at gitlab . The sections below refer to software included in LibreLAMP.
1. OpenSSL API
This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (https://www.openssl.org/)
1https://gitlab.com/Pipfrosch/librelampdocumentation
ii Legal Stuff
This product includes cryptographic software written by Eric Young ([email protected])
A copy of the OpenSSL license is included in the section entitled “Dual OpenSSL and SSLeay License” on page 46.
2. Apache
This product includes software including but not limited to the Apache Web Server that are licensed under the terms of the Apache 2.0 license.
A copy of the Apache 2.0 license is included in the section entitled “Apache 2.0 License” on page 49.
3. MariaDB
This product includes software including but not limited to the MariaDB database server that are licensed under the terms of the GNU General Public License (GPL) version 2.0.
A copy of the GNU GPL 2.0 is included in the section entitled “GNU General Public License version 2.0” on page 54.
This product includes software libraries including but not limited to the MariaDB C Client library that are licensed under the terms of the GNU Lesser General Public License (LGPL) version 2.1.
A copy of the GNU LGPL 2.1 is included in the section entitled “GNU Lesser General Public License version 2.1” on page 62.
4. PHP
This product includes PHP software, freely available from https://www.php.net/software/ PHP is licended under the terms of The PHP License, version 3.01.
A copy of The PHP License, version 3.01 is included in the secton entitled “The PHP License, version 3.01” on page 71.
iii Contents
Legal Stuff ii 1. OpenSSL API...... ii 2. Apache...... iii 3. MariaDB...... iii 4. PHP...... iii
1. Introduction1 1.1. Software Version Philosophy...... 2 1.2. FIPS Disclosure...... 3 1.3. TLS 1.3 Disclosure...... 3 1.4. System Libraries...... 4 1.5. GnuTLS...... 4 1.6. Mail Stack...... 5 1.7. DNS Stack...... 5 1.8. Other Servers...... 6
2. LibreLAMP Installation7 2.1. Enable EPEL...... 7 2.2. Install HAVEGED (optional)...... 7 2.3. Backup and Stop MariaDB...... 8 2.4. Install LibreLAMP...... 8 2.4.1. YUM Bug Note...... 8
I. Apache Web Server 10
3. Basic Apache Setup and Configuration 11 3.1. Apache Install...... 11 3.2. IP Network Note...... 11 3.3. Webmaster Account...... 12 3.4. OCSP Stapling...... 12 3.5. Create the Document Root...... 13 3.6. Virtual Host Configuration...... 14 3.6.1. Port 80 Redirects...... 15 3.6.2. Port 443 Redirects...... 15 3.7. Live Server Virtual Host...... 16
iv Contents
4. Apache and TLS (SSL) 18 4.1. Server Certificate...... 18 4.1.1. Server Private Key Generation...... 19 4.1.2. Server CSR Generation...... 20 4.2. Cipher Suite Configuration...... 23 4.2.1. The Cipher Spec...... 24 4.2.2. Key Exchange...... 25 4.2.3. Cipher Choice...... 27 4.2.4. Authenticated Encryption with Associated Data (AEAD)...... 28 4.2.5. Cipher Block Size...... 30 4.2.6. Alice’s Recommended Cipher Spec...... 30 4.3. Strict Transport Security...... 31 4.3.1. The max-age Parameter...... 32 4.3.2. The Optional includeSubdomains Parameter...... 32 4.3.3. The Optional preload Parameter...... 32 4.4. TLDR Nutshell Bullet List...... 33
II. General Appendices 34
A. 128-bit Block Ciphers 35
III. Licenses 37
GNU Free Documentation License 38 1. APPLICABILITY AND DEFINITIONS...... 38 2. VERBATIM COPYING...... 40 3. COPYING IN QUANTITY...... 40 4. MODIFICATIONS...... 40 5. COMBINING DOCUMENTS...... 42 6. COLLECTIONS OF DOCUMENTS...... 43 7. AGGREGATION WITH INDEPENDENT WORKS...... 43 8. TRANSLATION...... 43 9. TERMINATION...... 44 10. FUTURE REVISIONS OF THIS LICENSE...... 44 11. RELICENSING...... 44 ADDENDUM: How to use this License for your documents...... 45
Dual OpenSSL and SSLeay License 46 LICENSE ISSUES...... 46 OpenSSL License...... 46
v Contents
Original SSLeay License...... 47
Apache 2.0 License 49 1. Definitions...... 49 2. Grant of Copyright License...... 50 3. Grant of Patent License...... 50 4. Redistribution...... 50 5. Submission of Contributions...... 51 6. Trademarks...... 51 7. Disclaimer of Warranty...... 52 8. Limitation of Liability...... 52 9. Accepting Warranty or Additional Liability...... 52 APPENDIX: How to apply the Apache License to your work...... 53
GNU General Public License version 2.0 54 Terms and Conditions For Copying, Distribution and Modification...... 55 Appendix: How to Apply These Terms to Your New Programs...... 60
GNU Lesser General Public License version 2.1 62 Terms and Conditions For Copying, Distribution and Modification...... 63 How to Apply These Terms to Your New Libraries...... 70
The PHP License, version 3.01 71
IV. Man Pages 73
B. LibreSSL configuration files 75 B.1. DESCRIPTION...... 75 B.2. OPENSSL LIBRARY CONFIGURATION...... 76 B.2.1. ASN1 Object Configuration Module...... 76 B.2.2. Engine Configuration Module...... 77 B.3. FILES...... 78 B.4. EXAMPLES...... 78 B.5. SEE ALSO...... 80 B.6. CAVEATS...... 80 B.7. BUGS...... 81 B.8. Man Page Notes and Legal...... 81
C. X.509 V3 certificate extension configuration format 83 C.1. DESCRIPTION...... 83 C.2. STANDARD EXTENSIONS...... 84 C.2.1. Basic constraints...... 84
vi Contents
C.2.2. Key usage...... 84 C.2.3. Extended key usage...... 84 C.2.4. Subject key identifier...... 85 C.2.5. Authority key identifier...... 85 C.2.6. Subject alternative name...... 86 C.2.7. Issuer alternative name...... 86 C.2.8. Authority info access...... 87 C.2.9. CRL distribution points...... 87 C.2.10. Issuing distribution point...... 88 C.2.11. Certificate policies...... 88 C.2.12. Policy constraints...... 89 C.2.13. Inhibit any policy...... 90 C.2.14. Name constraints...... 90 C.2.15. OCSP no check...... 90 C.2.16. TLS Feature (aka must staple)...... 90 C.3. DEPRECATED EXTENSIONS...... 90 C.3.1. Netscape string extensions...... 91 C.3.2. Netscape certificate type...... 91 C.4. ARBITRARY EXTENSIONS...... 91 C.5. FILES...... 92 C.6. SEE ALSO...... 92 C.7. HISTORY...... 92 C.8. CAVEATS...... 92 C.9. Man Page Notes and Legal...... 93
V. Acronyms and Glossaries 95
Acronyms 97
Main Glossary 100
HTTP Status Codes 106
vii 1. Introduction
This documentation project is currently rough draft and lacks some major sections. In 2012, the OpenSSL project added an extension called the Heartbeat extension and they en- abled the feature by default. What heartbeat does, it allows for Transport Layer Security (TLS) over User Datagram Protocol (UDP) or with a frequently changing Internet Protocol (IP) address. The vast majority of use cases for OpenSSL had absolutely no need for the extension, yet it was enabled by default. It can be a useful feature for some users, but the use cases are so few that it probably should be provided by a custom TLS library for those use cases. In 2014 it was discovered that the Heartbeat extension in OpenSSL had a serious flaw: It con- tained a buffer over-read vulnerability that could be used to compromise the private cryptography key associated with the server X.509 certificate, or other sensitive data. The vulnerability is de- scribed in CVE 2014-01601. The bug was fixed in OpenSSL, but the bug was the proverbial “straw that breaks the camel’s back” for the OpenBSD developers. They were already very frustrated with the OpenSSL project, the project ignored many old bugs while adding new features and retained a lot of legacy code to continue supporting deprecated outdated systems that made the code more complex than it needed to be. So OpenBSD forked OpenSSL to create the LibreSSL2 project. While many UNIX users are very tribal about their particular brand of UNIX, the LibreSSL developers understand that a fork of OpenSSL with better developer leadership would be of benefit to system administrators who use other operating systems (including Windows) and help those system administrators, so part of the LibreSSL project involves LibreSSL Portable3 — code to build LibreSSL on other modern systems. I am one of those system administrators, my flavor of UNIX is the CentOS4 distribution of GNU/Linux. I suffer from paranoia. The problem is the paranoia I suffer frequently ends up to be true. I was paranoid that the U.S. government was violating our fourth amendment right and spying on us, many people called me crazy but the Edward Snowden leaks confirmed it. I had paranoia the National Security Agency (NSA) was inserting backdoors into cryptography protocols, it appears exactly that happened with Dual EC DRBG5. I have paranoia that the massive amount of user tracking that takes place will be used by nefarious parties to socially engineer the masses. That
1https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160 2https://libressl.org 3https://github.com/libressl-portable/portable 4https://www.centos.org/ 5https://blog.0xbadc0de.be/archives/155
1 1. Introduction happened in 2016 with facebook tracking data and fake news in a (possibly successful) attempt to change the outcome of the election by socially engineering the voters. I also have paranoia that backdoor are added to popular Open Source projects by adding features most people do not need (so the code is not as carefully analyzed and the ‘many eyes’ paradigm fails) yet the feature is enabled allowing it to be exploited. I do not know that the Heartbleed vulnerability is an example of an intentional backdoor so it would not be fair for me to claim such, but it certainly is a demonstration that the OpenSSL project was sucsceptible to that kind of backdoor insertion. Hopefully they no longer are but I do not know that. The philosophy of the LibreSSL developers was much more inline with the way I thought a TLS library should be developed. Using LibreSSL for the OpenSSL API reduces my paranoia. I first packaged LibreSSL for CentOS 7 on 2015 August 03 (LibreSSL 2.2.1) and have been building the Open Source server packages I use against LibreSSL ever since. I call the project LibreLAMP with ‘Libre’ referencing both LibreSSL and the general concept of ‘Free as in Freedom – Liberty – Libre’ and in reference to the acronym ‘Linux Apache MariaDB PHP’ (the M use to stand for MySQL but. . . )
1.1. Software Version Philosophy
I like a stable operating system. This is why I choose CentOS as my UNIX flavor of choice. The software in enterprise GNU/Linux distributions is not bleeding edge, but many of the operational bugs have been fixed, enterprise distributions are stable. They also are maintained for a long time, so one does not have to start with a new operating system version very often, they can take their time to migrate to new versions and wait for the major bugs to be fixed. However with a server stack that philosophy does not really work. There frequently are features in fresh ‘bleeding edge’ versions of server software that improve security and functionallity. This is why the server software in LibreLAMP is not just a rebuild of CentOS 7 packages against LibreSSL but is far more ‘bleeding edge’ than what ships in CentOS 7. The current version of Apache allows for HTTP version 2 (HTTP/2). The current version of MariaDB has significant performance benefits, as well as additional engines that are beneficial to enterprise database needs. The current version of People Hate Perl (PHP) has numerous enhance- ments over the crusty version in CentOS 7. Furthermore, many web application developers do not have the financial resources to support old versions of PHP so to keep web applications up to date, you need a modern PHP. When a system administrator runs into an issue that needs to be solved, the project mailing lists are a very useful resource. You are far more likely to get help if you are using a modern version of the project. This is why LibreLAMP is mostly modern software that installs on top of enterprise distribution that has mostly older software.
2 1. Introduction
1.2. FIPS Disclosure
LibreSSL is not Federal Information Processing Standards (FIPS) certified. The project has no desire to become FIPS certified. FIPS is very problematic. FIPS certification did not prevent the heartbleed vulnerability. FIPS certified the Dual EC DRBG pseudo-Random Number Generator (pRNG) despite the fact that knowledgeable cryptographers publicly expressed concerns a backdoor was present before FIPS specified it as one of a few pRNG options that FIPS certified software could use. While that pseudo-Random Number Generator is no longer part of FIPS, for a period of about four years systems that wanted to be FIPS certified were required to provide that pRNG despite the existing backdoor concerns we now know to be true. FIPS is dangerous in my opinion. Not all FIPS certified software used that pseudo-Random Number Generator but it still should not have been required to be there. The LibreSSL project is interested in actual security, not the false sense of security that results from FIPS certification. Do not use LibreLAMP if you are required to have FIPS certification, you will not meet the requirement. It may be a worthless requirement, but I believe it is my obligation to make sure lack of FIPS certification in LibreLAMP build of cryptography related software is known. The paranoid part of me wonders if the false sense of security that comes from FIPS certification is exactly what the government wants. Comfortable ignorance to potential backdoors.
1.3. TLS 1.3 Disclosure
At this time, LibreSSL does not support TLS 1.3. That may change by the time this documentation is finished. The LibreSSL developers made the decision not to start working on implementing TLS 1.3 until the draft was finalized. That actually is a decision I respect, even though it does result in a delay in implementation. It is being worked on now. The updated GnuTLS (see section 1.5 on page4) packaged in LibreLAMP does support TLS 1.3, as does LibreLAMP software that links against it, including the Exim Simple Mail Transfer Protocol (SMTP) server, the GNU’s Not UNIX (GNU) Wget Hyper-Text Transfer Protocol (HTTP) client, and the experimental GNU Wget2 HTTP client. The main benefit of TLS 1.3 is that it simplifies secure TLS implementation by requiring things like Forward Secrecy (FS) and Authenticated Encryption with Associated Data (AEAD) cipher suites. We can implement those same restrictions manually for TLS 1.2 and will have to anyway even when LibreSSL does implement TLS 1.3 simply because it will be some time before all clients support TLS 1.3.
3 1. Introduction
1.4. System Libraries
In addition to building updated server software, LibreLAMP updates some libraries. For example, the PHP module Imagick6 can not create WebP7 images in PHP unless the version of ImageMag- ick8 it is built against is new enough to support WebP. The version of ImageMagick in CentOS 7 is too old, so LibreLAMP updates it to the current version. This results in a shared library version change, so packages in CentOS 7 and Extra Packages for Enterprise Linux (EPEL) that link against the older ImageMagick library (such as Inkscape9) have to be rebuilt to use the newer updated shared library. This is why you will find many packages in LibreLAMP that seemingly have nothing to do with a server stack. The alternative is to build compatibility packages with the correct version of the shared libraries those packages need and in some cases I do that. For example, I do not rebuild every single piece of software in CentOS 7 and EPEL that link against MariaDB but instead I choose to provide a compatibility package that does provide the older shared library versions those packages need.
1.5. GnuTLS
The OpenSSL API is not the only game in town, and honestly I am not sure it is the best. A lot of server software chooses that API hence the need for a library that provides it, but diversity is good. CentOS 7 ships with GnuTLS10 but it is an older version. LibreLAMP has provided a rebuild of that version (needed because LibreLAMP upsates unbound11 resulting in a shared library in- compatibility if the CentOS version of GnuTLS is not rebuilt against the newer Unbound) but in December 2018 I also started providing the current version of GnuTLS provided as a compatibility package with an install prefix of /opt/gnutls. Having the current version of GnuTLS available allows me to provide an updated version of GNU Wget12 that includes TLS 1.3 support. While wget is not specifically server software, it frequently is used on servers and having a modern version with HTTP/2 and TLS 1.3 support is beneficial. Additionally, the modern version of GnuTLS allows for building the modern version of Exim with improved DomainKeys Identified Mail (DKIM) support.
6https://pecl.php.net/package/imagick 7https://developers.google.com/speed/webp/ 8https://imagemagick.org/index.php 9https://inkscape.org/ 10https://gnutls.org/ 11https://nlnetlabs.nl/projects/unbound/about/ 12https://www.gnu.org/software/wget/
4 1. Introduction
1.6. Mail Stack
The Postfix13 that ships in CentOS 7 is too old for DNS Authentication of Named Entities (DANE) support. DANE is very important for user privacy, so LibreLAMP includes an updated version of Postfix with DANE support. I do not like how centralized e-mail service has become. A very large percentage of all e-mail passes through Google, Microsoft, or Yahoo controlled mail servers. The opportunity for abuse is very high, and tech companies seem to always believe their violation of user privacy is justified. It is not just tech companies, Kamala Harris said that when she had low income parents ar- rested because their children missed too many days of school, she was actually helping them. Pete Buttigieg said that when he demolished houses in low income neighborhoods, he did so to combat the drug problems in those neighborhoods. Elites in our society very frequently believe they are justified in violating our rights. It is a serious problem and is why centralization of e-mail services is very dangerous. If that centralization is not being abused now, it certainly will be in the future, I guarantee it. LibreLAMP provides a modern of Dovecot so that those who wish to run their own mail box services and avoid the centralization taking place can do so with a modern Dovecot linked against LibreSSL. I have started to become frustrated with the Postfix project. It seems almost every time there is an update to either LibreSSL or Postfix, something breaks. Often Postfix still builds and unit tests pass, but there is still breakage that I do not detect until I view the mail logs. The Postfix Developers are not very concerned about remaining compatibility with the LibreSSL fork of OpenSSL and to be completely honest, it would not be fair for me to expect them to. It is frustrating though, attempting to ask for help on their list is met by developers responding ‘Use OpenSSL’. Exim14 in very committed to support for the GnuTLS API, so LibreLAMP is currently providing builds of the current version of Exim built against GnuTLS. I personally still use Postfix for everything Port 25 related, Postfix has a lot of very useful features including but limited to Postscreen that I do not yet know how to accomplish in Exim. However I am now switching to Exim for web servers that need to send e-mail but do not listen on Port 25.
1.7. DNS Stack
Every server on the Internet, every single one, really should run a local DNS Security Extensions (DNSSEC) enforcing caching name server. This is critical to security. LibreLAMP includes the current version of Unbound15 to provide this.
13http://www.postfix.org/ 14http://exim.org/ 15https://nlnetlabs.nl/projects/unbound/about/
5 1. Introduction
For those who wish to run their own Authoritative Domain Name System (DNS) server, LibreLAMP includes the current version of NSD16. Both Unbound and NSD have a much better security record than BIND. LibreLAMP also includes some updated DNS related libraries so that some of the recently added record types are better supported with zone file validation tools.
1.8. Other Servers
In addition to the stacks mentions, some other server software (e.g, ProFTPD) have been built using LibreSSL for CentOS 7.
16https://www.nlnetlabs.nl/projects/nsd/about/
6 2. LibreLAMP Installation
LibreLAMP is a collection of packages that run on top of CentOS 7 with EPEL. LibreLAMP only provides packages for the x86 64 binary platform. If you need it for another platform, feel free to buy me the hardware I need (sorry, cross-compiling sucks, I will not do it). If you are looking for a Virtual server, Linode1 provides excellent service and has CentOS 7 images to use. Yes, that is an affiliate link but yes, I have been using Linode for over a decade now and they are excellent.
2.1. Enable EPEL
To enable the EPEL package repository:
[root@host ˜]# rpm -q epel-release
If that package is not already installed, in CentOS 7 you can install it with the following com- mand:
[root@host ˜]# yum -y install epel-release
In either case, make sure the system is up to date:
[root@host ˜]# yum update
2.2. Install HAVEGED (optional)
The haveged daemon is an implementation of the Hardware Volatile Entropy Gathering and Ex- pansion (HAVEGE) algorithm. It is useful for increasing the entropy pool on your system. I recommend it.
[root@host ˜]# yum -y install haveged [root@host ˜]# systemctl enable haveged.service [root@host ˜]# systemctl start haveged.service
1https://www.linode.com/?r=8cc9ab7df08da8c6aab1b36fbf3d61762062aa6a
7 2. LibreLAMP Installation
2.3. Backup and Stop MariaDB
If you already have MariaDB set up with databases, the MariaDB in LibreLAMP is a major version update. With major updates to database server software, it is highly recommended you perform a fresh back-up first and stop the database server. That way you can recover if bad things happen. Things will probably be okay if you do not take this precautionary step, but if things are not okay and you do not have backup, you may be fucked.
2.4. Install LibreLAMP
You can now install LibreLAMP with the following commands:
[root@host ˜]# curl -O https://librelamp.com/awel-libre-release-7-3.noarch.rpm [root@host ˜]# rpm -ih awel-libre-release-7-3.noarch.rpm [root@host ˜]# yum update postfix [root@host ˜]# rpm -e mariadb-libs [root@host ˜]# yum clean all && yum update
If the above fails, I apologize, it is a bug in YUM. An explanation and workaround is below.
2.4.1. YUM Bug Note MariaDB packaging has changed. In new versions of MariaDB, software that links against the MariaDB libraries now uses a package called mariadb-c-connector for the libraries. The mariadb-libs package no longer contains the client library does not contain the /etc/my.cnf file and that confuses YUM. That file is now provided by the mariadb-config package. YUM has trouble figuring it out. First, update Postfix if you did not already. The Postfix in CentOS 7 links against the CentOS 7 mariadb-libs but the Postfix in Librelamp does not.
[root@host ˜]# yum update postfix
Next, find out what else on your system (if anything) links against the old mariadb-libs package:
[root@host ˜]# rpm --test -e mariadb-libs
If there are still any packages that depend upon the CentOS 7 mariadb-libs package, that will tell you what they are. Try manually updating those packages the same way Postfix was updated. There is a decent change LibreLAMP has updates to them that do not depend upon the CentOS 7 mariadb-libs package. Now the problematic mariadb-libs package can be removed:
8 2. LibreLAMP Installation
[root@host ˜]# rpm -e mariadb-libs
Updating to the rest of LibreLAMP should now work:
[root@host ˜]# yum clean all && yum update
I apologize that you likely have to go through that process. Seth Vidal, a brilliant developer and the maintainer of YUM, was killed by a motorist while riding his bicycle in Durham, NC. Since then, Red Hat has been putting most of its focus into a new update system called DNF so it is not likely this dependency resolution bug will be fixed.
9 Part I.
Apache Web Server
10 3. Basic Apache Setup and Configuration
3.1. Apache Install
After making sure your CentOS 7 install is up to date and the LibreLAMP YUM package repository has been enabled (see chapter2 on page7), run the following commands:
[root@host ˜]# yum update [root@host ˜]# yum install httpd mod_ssl
The first command will make sure your system is up to date. You can skip that if you have just updated. The second command will install Apache and the mod ssl module if they are not already in- stalled, along with any dependencies. Now configure Apache to start at system book, and manually start it:
[root@host ˜]# systemctl enable httpd.service [root@host ˜]# systemctl start httpd.service
3.2. IP Network Note
It is very common for webmasters to only configure Apache to handle IPv4 requests. If your hosting facility does not provide you with an IPv6 address, your hosting facility is living in the past. Find a new one. If your hosting facility does provide you with an IPv6 address, please create the appropriate AAAA records in your DNS zone file so that your domain names resolve on the IPv6 network and configure Apache virtual hosts that listen on IPv6 as well as on IPv4. On cellular networks most devices connect through IPv6. While they can still retrieve data from the IPv4 network, the requests need to go through a NAT64 mechanism to do so. It works, but it is better if it does not have to. Please please make sure you deploy IPv6. For more information, see the Internet Society IPv61 guide.
1https://www.internetsociety.org/deploy360/ipv6/
11 3. Basic Apache Setup and Configuration
3.3. Webmaster Account
Every web site should have what I like to call a webmaster account. The same webmaster account can be used for multiple websites hosted on the server, though you can have different webmaster accounts for different websites. The webmaster account is a UNIX user account on the system that has permission to write files in the web site Document Root and administer the databases associated with the web site, but it does not have permission to modify Apache configuration files (other than the .htaccess files with the Document Root) or modify other system configuration files. If the person who is the webmaster for a site is also the system administrator, a different UNIX user account should be used to log in and perform those tasks. Most webmaster duties do not require a privileged UNIX user account, and webmasters tend to log in from a wide variety of locations using many different devices, increasing the risk that the account they use for webmaster duties will become compromised. Hopefully that will never happen to you, but it does happen. When it does happen, it is better if the compromised account does not even have the ability to become the root user and does not have the ability to use sudo to do things only the root user should be able to do, like read the private X.509 cryptography keys or install new Public Key Infrastructure (X.509) (PKIX) root trust anchors or reconfigure your SMTP server to act as a spam relay. The webmaster probably should have privileges to administer the databases associated with web sites and generally should have permission to create and drop databases, those privileges are often needed for the proper administration of web applications. When updating web applications and the database structure changes, some webmasters will clone the database to a new one and perform the update using the new one keeping the old database perfectly intact, allowing them to quickly revert if there is an issue. The webmaster probably should have GRANT privileges on the database. Creating new database users for each web application is a very good practice. If your webmaster is competent, they will not see this separation of privilege as a burden but will appreciate it.
3.4. OCSP Stapling
Historically, Certificate Authorities maintained a Certificate Revocation List (CRL) that clients could check to make sure trust in a X.509 certificate had not been revoked. That solution did not scale well, the lists became too large so clients would implicitly trust a certificate if it was not able to estabish a connection to the CRL server, a frequent exploitable condition. RFC 69602 defines Online Certificate Status Protocol (OCSP) as a solution to this problem. With OCSP, the client does not need to retrieve a large list of revoked certificates just to verify the
2https://tools.ietf.org/html/rfc6960
12 3. Basic Apache Setup and Configuration certificate it is interested in validating is not part of that list. When a Certificate Authority (CA) supports OCSP, the client can ask about the specific certificate. To even further mitigate the problem, a server can make the OCSP request and cache the result, sending it to the client along with the handshake. As the OCSP response is signed by theCA and short-lived, the client can have confidence that it is valid. As the server caches the response, it can send the cached response to every client making a request so those clients do not need to make individual OCSP requests themselves, greatly reducing the load on the OCSP server. This is called ‘OCSP Stapling’. Not all servers support OCSP stapling, but Apache does. By default LibreLAMP enables OCSP Stapling on a global level, it applies to every virtual host. However if you are upgrading an existing Apache install to the Apache that ships with LibreLAMP, it is possible that RPM Package Manager (RPM) preserved the old configuration and it is still active. Look at the file /etc/httpd/conf.d/ssl.conf and make sure it contains the following:
1 ## 2 ## OCSP Stapling 3 ## 4 5 SSLUseStapling On 6 SSLStaplingCache "shmcb:/run/httpd/ssl_stapling(65536)"
If it does, you are all set. If it does not, add it but make sure it is added outside the context of the Port 443 default virtual host. If the old CentOS /etc/httpd/conf.d/ssl.conf is still active, the LibreLAMP modified version with OCSP is probably there too but likely named ssl.conf.rpmnew. If that is the case, the following will install the default LibreLAMP configuration for that file:
[root@host ˜]# pushd /etc/httpd/conf.d [root@host conf.d]# cp -p ssl.conf ssl.conf.old.save [root@host conf.d]# cat ssl.conf.rpmnew > ssl.conf [root@host conf.d[# systemctl restart httpd.service
Generally, the ssl.conf file should be left alone, TLS specific changes should be made in the website specific virtual hosts. Do however make sure that OCSP Stapling is enabled globally in that file.
3.5. Create the Document Root
The Apache Daemon serves content for a web site from within what is called the Document Root for that web site. When no virtual hosts for a host are defined, the system-wide default Document Root on CentOS systems is /var/www/html but it is generally considered a good practive to create virtual hosts
13 3. Basic Apache Setup and Configuration with their own Document Root for each virtual host and to give the site webmaster account write permission to the Document Root. I generally like to create such directories with the /srv directory and make the Document Root a sub-directory of a directory named after the domain it is being used for. For example, if my webmaster user account is alice and the domain is example.org I would create the Document Root for it using the following commands:
[root@host ˜]# cd /srv [root@host srv]# mkdir -p example.org/www [root@host srv]# mkdir example.org/phpinclude [root@host srv]# chown -R alice:alice example.org
The Document Root for Apache is now created as /srv/example.org/www and the user ac- count alice has permission to place files in it, as well as permission to create some files that are outside the Document Root. PHP include files (such as a database connection script that includes authentication credentials) can be placed in the /srv/example.org/phpinclude directory where PHP can be configured to find them but Apache will not accidentally serve them as text files if the PHP module breaks.
3.6. Virtual Host Configuration
Apache allows you to configure different responses based upon theIP address, Port, and domain name associated with request. These configurations are called Virtual Hosts. A virtual host starts by specifying theIP address and port the configuration is applicable to, with theIP address and port separated by a colon.
1
For IPv6 addresses, as the address itself includes colons, the address must be enclosed within [] square brackets. Directly after the openening
1
While not strictly required, it is best practice to have a separate file for each domain to contain the virtual host configurations related to that domain. For example.org I would name the file example.org.conf for clarity, but what you name it
14 3. Basic Apache Setup and Configuration does not matter too much. As long as it ends with .conf and is located within the /etc/httpd/- conf.d directory, Apache will read it when it starts. Usually the file will include several virtual hosts (for redirects, IPv4, and IPv6 as well as a few other directives, such as defining access permission to the Document Root. Historically, websites often used a ‘www’ sub-domain for their content. This was due to the web server itself often running on a different host than the registered domain name. That is now rarely the case. If you are using the ‘www’ sub-domain (e.g. www.example.org) then you should a virtual host defined within the configuration file that lacks the ‘www’ sub-domain (e.g. example.org) redirect requests to the version with the sub-domain, but if you are serving the content from the registered domain name itself, then you should do the opposite. My personal preference is to redirect from the ‘www’ sub-domain to the registered domain name but there is not a technical reason for this preference. The LibreLAMP build of Apache follows the Red Hat (and Fedora) tradition of placing these files within the directory /etc/httpd/conf.d/.
3.6.1. Port 80 Redirects If your firewall is blocking Port 80 then you do not strictly need to do this, but it does not hurt to do this anyway. If your firewall is not blocking port 80 then you must do this so that requests to the insecure Port 80 get redirected to your secure server. This section assumes that you are using example.org with requests to www.example.org redirecting to it.
1 #Port 80 Redirect 2 3
Repeat the same two redirect virtual hosts for your IPv6 address, remembering that Apache requires an IPv6 address to be enclosed within [] square brackets. The Redirect permanent directive causes Apache to send a 301 Moved Permanently header so that clients will remember the redirect and automatically apply the redirect the next time they are asked to make a request to the same domain name without needing to be told.
3.6.2. Port 443 Redirects If you want all requests made to www.example.org to redirect to example.org then you need to set a redirect virtual host for www.example.org on Port 443 as well.
15 3. Basic Apache Setup and Configuration
This virtual host will require a few more directives as TLS is involved.
1 #Port 443 Redirects 2 3
For a description of the Strict-Transport-Security directive on line number 5, please refer to section 4.3 on page 31. For a description of the SSLHonorCipherOrder and SSLCipherSuite directives on line numbers 8 and 9, please refer to section 4.2 on page 23. For a description of the certificate related directives on lines 10–12, please refer to section 4.1 on page 4.1. For a description of the log directives on lines 13 and 14, please refer to section ?? on page ??.
3.7. Live Server Virtual Host
With the redirects taken care of, it is now time to configure the live host that actually serves data. For example.org the configuration would look something like this:
1 # Live server 2 3
The only difference from the Port 443 redirect is that a DocumentRoot directive has been added while the Redirect directive has been removed. Again remember to also make a virtual host for your IPv6 address.
16 3. Basic Apache Setup and Configuration
Apache now knows where to find the documents to serve, but it will not serve them, it will respons with a 403 Forbidden error. For the server to work, Apache needs to be told who it is allowed to serve files in the Docu- mentRoot to. This is accomplished with a
17 4. Apache and TLS (SSL)
When TLS was first invented, it was called Secure Socket Layer (SSL) and it is still often referred to that way. TLS is now the correct terminology. SSL 1.0 was never released because serious flaws were found in it before release. SSL 2.0 and 3.0 were released but are no longer considered to be secure. The LibreSSL library that Apache in LibreLAMP uses for TLS does not support those protocols. TLS 1.0 and 1.1 are on the path to deprecation and will likely no longer be supported by the major browser vendors in releases after March 2020. It is my strong recommendation that you only support TLS 1.2 and newer. TLS 1.2 was originally defined in RFC 52461. TLS 1.3 was originally defined in RFC 84462. At this time, the LibreSSL library does not yet support TLS 1.3 however work is being done towards that end and it will likely be supported in the next major version release of LibreSSL. The main advantage of TLS 1.3 over 1.2 is that configuration mistakes are less likely to result in an attack surface. By following these instructions, you can be confident those attack surfaces do not exist even with TLS 1.2.
4.1. Server Certificate
Historically the Server Certificate was used for both authentication of the server to the client and as part of the key exchange. That latter purpose is dangerous, it potentially allows logged encrypted sessions to be decrypted in the future if the attacker ever compromises the server private key. There are two types of server certificates commonly supported by clients. They are classified by the algorithm type used for the public/private key pair.
• Rivest-Shamir-Adleman (RSA) certificates are supported by every client capable of TLS.
• Elliptic-Curve Digital Signature Algorithm (ECDSA) certificates are supported by the vast majority of clients capable of TLS. A few outdated clients can not handle them, but such clients should not be considered secure anyway because their code is old.
When in doubt, always use ECDSA certificates with a TLS Secured HTTP (HTTPS) server. The only reason to use an RSA certificate today is if you are running a utility server where you know some outdated non-human clients (e.g. embedded devices) will need to connect to your resource. Such legitimate use cases are really rare these days.
1https://tools.ietf.org/html/rfc5246 2https://tools.ietf.org/html/rfc8446
18 4. Apache and TLS (SSL)
When you absolutely must use an RSA server certificate, 2048-bit is safe but I usually prefer 3072-bit for the key size. Never use an RSA key size smaller than 2048-bit. When you use an ECDSA certificate, there are currently only two choices widely supported by clients:
• prime256v1 (P-256)
• secp384r1 (P-384)
The P-384 curve is considered to be the stronger of the two which is why I generally use that curve. For server authentication, it is roughly equivalent to a 7680-bit RSA key. The P-256 curve is roughly equivalent to a 3072-bit RSA key. Those rough equivalents do have some Apples to Oranges qualities to the comparisons, but they are good guidelines when choosing an Elliptic-Curve (EC) curve based upon what your needs for an RSA key size would be. Please note that theEC curve selected has nothing to do with the strength of the cryptography encipherment. It only is used to authenticate your server to the client, it does not serve an en- cryption purpose. It only needs to be strong enough to be secure today, whether or not the private ECDSA key is easily crackable five years from today does not matter. With that in mind, P-256 may sometimes be the better choice as it is a little easier on both the client and server, so P-256 is probably what you should use on very high traffic servers. For moderate and low traffic server, the extra server load of P-384 never really is an issue and in my personal experience with outdated hardware, the performance difference for the client is not noticeable to humans.
4.1.1. Server Private Key Generation This section is provided for completeness. The LibreLAMP librelamp-keygen package pro- vides shell scripts that does this for you. If you want to manually generate a private key for an ECDSA key pair, make sure you are the root user and issue the following commands:
[root@host ˜]# umask 0277 [root@host ˜]# pushd /etc/pki/tls/private [root@host private]# /usr/bin/libressl ecparam -name secp384r1 -genkey -out \ example.org-`date +%Y%m%d`.key [root@host private]# popd
Obviously change example.org to your domain name. If you would prefer P-256 over P-384 then change secp384r1 to prime256v1 in the above commands. To generate a private key for an RSA key pair, make sure you are the root user and issue the following commands:
19 4. Apache and TLS (SSL)
[root@host ˜]# umask 0277 [root@host ˜]# pushd /etc/pki/tls/private [root@host private]# /usr/bin/libressl genpkey \ -algorithm RSA -pkeyopt rsa_keygen_bits:3072 \ -out example.org-`date +%Y%m%d`.key [root@host private]# popd
Obviously change example.org to your domain name. If you would prefer a 4096-bit private key, change the 3072 to 4096. In both the ECDSA and RSA example, the purpose of the umask 0277 command is to make sure only the root user has permission to read the file. It is a private key. The result is a file using the domain name and date for the file name.
4.1.2. Server CSR Generation This section is provided for completeness. The LibreLAMP librelamp-keygen package pro- vides shell scripts that does this for you. A Certificate Signing Request (CSR) is needed to obtain a signed certificate from aCA. I find it best to create a custom configuration file when generating one. For the domain example.org I would name the configuration file example.org.csr.cfg and it would look something like this:
1 [req] 2 distinguished_name = dn 3 req_extensions = ext 4 prompt = no 5 6 [dn] 7 C = US 8 ST =Washington 9 L = Seattle 10 O =YourCompanyName 11 CN =example.org 12 emailAddress = [email protected] 13 14 [ext] 15 basicConstraints = critical,CA:FALSE 16 keyUsage = critical,digitalSignature 17 extendedKeyUsage = serverAuth,clientAuth 18 subjectAltName = @san 19 1.3.6.1.5.5.7.1.24 = DER:30:03:02:01:05 20 21 [san] 22 DNS.0 =www.example.org
For full details on CSR configuration options, please see the libressl.cnf(5) man page (appendixB on page 75) and the x509v3.cnf(5) man page (appendixC on page 83).
20 4. Apache and TLS (SSL)
OCSP Stapling In the above example configuration file, line 19 instructs theCA to issue a certificate that requires OCSP stapling. This is the x509v3 extension referred to as tlsfeature in section C.2.16 on page 90. This feature is defined in RFC 76333. The /usr/bin/libressl binary in LibreLAMP under- stands the tlsfeature extension, but the /usr/bin/openssl binary that ships with CentOS 7 does not. For that reason, I use the raw Distinguished Encoding Rules (DER) method described in section C.4 on page 91 when adding that to a CSR. That ensures the CSR will properly generate even if the CentOS provided /usr/bin/openssl binary is used. What the extension actually does is very important. It tells the client to refuse the certificate if the certificate does not have a valid OCSP response stapled to it. This can prevent attacks using a compromised private key that has properly been revoked after it was discovered to be compromised. However Do not use that extension with self-signed certificates. Also do not use that certificate with server software that does not yet support OCSP stapling, such as ProFTPD and most mail servers. Apache in LibreLAMP performs OCSP stapling by default. It is safe and highly recommended to use that extension when generating a CSR for a certificate used by Apache.
Subject Alternative Name In the above example configuration file (page 20), line 18 and lines 21-22 are used to configure the subjectAltName feature. The subjectAltName feature is described in section C.2.6 on page 86 but it does not do a very good job at explaining it for our context, not even a basic example. A x509 certificate used by a web server without that feature will only be valid for a single domain name, the name defined by the CN parameter. Usually we also want the certificate to also be valid for the www sub-domain. Most commercialCAs will allow you to specify the www sub-domain with the subjectAlt- Name feature for free, and some even do it automatically even if you do not specify it. However be aware that if you use that feature for other sub-domains (or additional domains) they generally will charge you extra.
Genrate the CSR file With the configuration file created and containing the correct information, you can now generate a CSR to submit to aCA for signing.
3https://tools.ietf.org/html/rfc7633
21 4. Apache and TLS (SSL)
[root@host ˜]# libressl req -new \ -key "/etc/pki/tls/private/example.org-`date +%Y%m%d`.key \ -config "/path/to/example.org.csr.cfg" \ -out "example.org-`date +%Y%m%d`.csr"
How you submit the CSR depends upon theCA. Usually they have a form where you just copy and paste the contents of the file, which is base64 encoded and looks like gibberish.
Self-Signed Certificate With HTTPS a self-signed certificate should never be used on a public server. Clients will rightfully warn the user, and in some cases will outrightly refuse to connect. The quality of the encryption is not an issue, the issue is that the client has no mechanism by which it can validate you are who you say you are. Even when clients support DANE validation, I suspect (and hope) they refuse to play nice with self-signed certificates. The issue has to do with Phishing and Certificate Transparency. The latter helps avoid the former but is not available with DANE validation alone. To generate a self-signed certificate for internal use, create a example.org.csr.cfg file con- taining the following:
1 [req] 2 distinguished_name = dn 3 req_extensions = ext 4 prompt = no 5 6 [dn] 7 CN =example.org 8 9 [ext] 10 basicConstraints = critical,CA:FALSE 11 extendedKeyUsage = serverAuth,clientAuth 12 subjectAltName = @san 13 14 [san] 15 DNS.0 =www.example.org
You can then generate your self-signed certificate with the following commands:
[root@host ˜]# umask 0022 [root@host ˜]# pushd /etc/pki/tls/certs [root@host certs]# libressl req -new -days 370 \ -key "/etc/pki/tls/private/example.org-`date +%Y%m%d`.key \ -config "/path/to/example.org.csr.cfg" \ -out "example.org-SS-`date +%Y%m%s`.crt"
That will generate a self-signed certificate that is valid for 370 days. The purpose of the umask 0022 command is to make sure the certificate can be read by anyone. It will contain the public key from your key pair.
22 4. Apache and TLS (SSL)
4.2. Cipher Suite Configuration
In Cryptography, a cipher is an algorithm for obfuscating a plaintext message using a secret key in such a way that (unless the cipher is broken) the obfuscated message can only be returned to plaintext if the secret (often referred to as the key) is known. A cipher suite is a collection of algorithms including the cipher that in the context of TLS also includes the key exchange (e.g. RSA or EECDH), cipher family (e.g. AES or DES), key size (e.g. 128-bit or 256-bit), mode (e.g. CBC or GCM), and the Message Authentication Code (e.g. SHA or SHA256). The cipher suites used by Apache are selected from what is called a Cipher Spec. You specify certain characteristics and all ciphers that meet that spec are added to the list. After you have specified all the different parameters, you then specify filter parameters to remove cipher suites that matched your parameters but have other characteristics you do not want. With all those different aspects to a cipher suite, it can be difficult for someone without a firm grasp on cryptography to grasp what they need to do to select what ciphers they should allow and how to order them for the best security. Unfortunately the web is a horrible resource for understanding this. If you do not already have a basic grasp on cryptography concepts, it can be difficult to distinguish the bullshit from what is legitimate. This has resulted in many websites giving really bad advice, even websites published by al- legedly knowkedgeable organizations. This is an example cipher spec that is absurd yet is voted up as a knowledgeable answer at StackExchange:
1 SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128: 2 DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
It includes some dangerous options, but in fairness it is an older answer. However what really makes it dangerous, it is too complex. Keep It Short and Simple (KISS) is a fundamental concept too many do not grasp. The more complex a cipher spec is, the harder it is for a system administrator to get a handle on what ciphers are chosen. Less is More is another concept too many do not grasp. It does not matter if a cipher suite is currently considered secure. Do not configure Apache to use it if it is not absolutely 100% needed. At the time the bad example cipher spec was posted, Tripple DES (3DES) was thought to be a safe cipher. However it was not needed by anyone with a remotely modern browser, the Advanced Encryption Standard (AES) ciphers were known to be more secure and were broadly supported. Now 3DES is known to be unsafe. Had that cipher list not included it, updating his cipher spec would not have become necessary once it was determined that 3DES is not safe. Do not increase your attack surface by including cipher suites that simply are not needed. Globally Blacklist unsafe algorithms. The bad example cipher spec includes the following pa-
23 4. Apache and TLS (SSL) rameter: !aNULL:!MD5:!DSS. It is good that he wants those ciphers excluded, but the Apache configuration is the wrong place to do it. A typo in the cipher spec means they would not be excluded. Always make sure mod ssl itself blacklists the dangerous cipher options. LibreLAMP Apache does this. In addition to :!aNULL:!eNULL:!EXP that upstream Apache already blacklists, Apache in LibreLAMP is patched to apply !SHA:!RC4:!3DES:!LOW. Always start by configuring Apache to only support the very best cipher suites, then use a tool like SSL Labs4 to check what clients it supports. Slowly add strong ciphers until you have the client support you need. Do not worry about about supporting old browsers that are no longer maintained, those browsers can not be considered secure anyway.
4.2.1. The Cipher Spec The Apache mod ssl uses what is called a Cipher Spec to determine which ciphers supported by the TLS library to support. It is defined using the SSLCipherSuite directive. The official Apache documentation for this module is somewhat lacking in clarity but it still is worth reading5. Basically the value of the directive is a list of rule sets. Each rule set is composed of one or tags delimited by a +. Rule sets for removing ciphers are preceded by a - and if present generally should appear at the end of the cipher spec or cipher suites that match may be added again. You can use also use a ! instead of a - and they will not be added again, but I personally prefer not to use ! except in code where I am not able to determine what other rule sets will be applied. The rule sets are delimited by either a space or a : colon character. Using a : in a configuration file is discouraged because it makes it harder for humans to read. When using a space as the delimiter between rule sets, the cipher spec must be enclosed with two upright " double quotation marks (one before first rule set, one after last rule set.
1 SSLCipherSuite EECDH+CHACHA20:EECDH+AESGCM:EECDH+AES256+SHA384
is equivalent to the easier to read
1 SSLCipherSuite "EECDH+CHACHA20 EECDH+AESGCM:EECDH AES256+SHA384"
Each rule set is evaluated in order (left to right) and any cipher suites the SSL library supports that match the rule set are added to the list of cipher suites Apache will use unless the rule set is preceded by a - or !, in which case it selects from previously added ciphers and removes them. The tag EDH corresponds with Diffie-Hellman Ephemeral (DHE) key exchange ciphers, so the rule set EDH would match every single cipher suite that uses DHE. The tag AES corresponds with
4https://www.ssllabs.com/ 5https://librelamp.com/manual/mod/mod_ssl.html#SSLCipherSuite
24 4. Apache and TLS (SSL)
AES cipher suites, so the rule set EDH+AES would match every cipher that uses DHE and the AES cipher. The tag SHA corresponds with cipher suites that use Secure Hash Algorithm 1 (SHA-1) for the Message Authentication Code (MAC)( note that Apache in LibreSSL already excludes these automatically) so we could add a second rule set -SHA that would filter out all cipher suites that use SHA-1 from what was previously add: EDH+AES -SHA The following table lists tags, their context, and meaning that are most likely to be of value when creating a cipher spec for Apache in LibreLAMP: tag context meaning EDH Key Exchange DHE Key Exchange Algorithm EECDH Key Exchange ECDHE Key Exchange Algorithm ECDSA X.509 Certificate ECDSA Certificate RSA X.509 Certificate RSA Certificate CHACHA20 Cipher ChaCha20-Poly1305 AES Cipher AES Cipher Family AESGCM Cipher + Mode AES Cipher Family with GCM Mode AES128 Cipher + Block Size AES Cipher with 128-bit blocks AES256 Cipher + Block Size AES Cipher with 256-bit blocks SHA256 MAC SHA-256 Message Authentication Code SHA384 MAC SHA-384 Message Authentication Code Note that the X.509 context only needs to be specified when you have configured Apache to use both ECDSA and RSA certificates. I do not recommend doing that. Using dual certificates may earn you geek street cred, but it is pointless and only had value when ECDSA certificates were still largely experimental. When only a single certificate is used, the type is automatically applied when evaluating the rule set.
4.2.2. Key Exchange Before a client and server can use encryption to communicate with each other, they have to nego- tiate a shared secret they both know that hopefully no one else knows or is able to figure out. This process is called the Key Exchange. There are several different types of key exchange, some are not as good as others. TLS 1.3 requires cipher suites that use aFS key exchange. TLS 1.2 allows for cipher suites that do not useFS but they should not be used even though they are allowed. With Forward Secrecy, the negotiated shared secret is ephemeral (short-lived) and is completely independent of the long-term keys used for the server (or client) certificates. If the NSA or any other nefarious party logs the encrypted session and then later manages to steal the long-term private certificate keys, it will be of no use in deciphering the encrypted session, hence the term Forward Secrecy.
25 4. Apache and TLS (SSL)
Currently there are two key exchange algorithms that provide Forward Secrecy: DHE and Elliptic-Curve Diffie-Hellman Ephemeral (ECDHE). DHE cipher suites can only be used when the server has an RSA certificate. ECDHE cipher suites can be used with either RSA or ECDSA server certificates. For a list of all LibreSSL cipher suites that use ECDHE key exchange you can use the command (below is with LibreSSL 2.9.2):
[user@host ˜]$ libressl ciphers |sed -e s?":"?"\n"?g |grep "ˆECDHE" ECDHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA384 ECDHE-ECDSA-AES256-SHA384 ECDHE-RSA-AES256-SHA ECDHE-ECDSA-AES256-SHA ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-RSA-CHACHA20-POLY1305 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-ECDSA-AES128-SHA256 ECDHE-RSA-AES128-SHA ECDHE-ECDSA-AES128-SHA ECDHE-RSA-RC4-SHA ECDHE-ECDSA-RC4-SHA ECDHE-RSA-DES-CBC3-SHA ECDHE-ECDSA-DES-CBC3-SHA
As you can see, the cipher suites are listed in a (mostly) human parseable order. The key exchange is listed first. Second is the type of X.509 certificate the key exchange works with. Third is the cipher, sometimes including a decimal representation of the block size in bits. Fourth is the mode if applicable, and if applicable it ends with the MAC. Further filtering for only ECDSA cipher suites excluding the weak SHA MAC that mod ssl in LibreLAMP Apache has been patched to exclude produces a much smaller list:
[user@host !]$ libressl ciphers |sed -e s?":"?"\n"?g |grep "ˆECDHE" \ > |grep "ECDSA" |grep -v "SHA$" ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES256-SHA384 ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES128-SHA256
We will further prune that list.
26 4. Apache and TLS (SSL)
DHE Not Recommended DHE is vulnerable to the Logjam Attack6 if the Diffie-Hellman (DH) parameters used are smaller than 2048-bit. TLS 1.3 mitigates the Logjam Attack by only allowing parameters from a pre-defined named group that has been well-studied. Current versions of Apache mitigate this with earlier versions of TLS by usingDH parameters that have the same number of bits as the long-term server private key with a minimum of 2048-bit. The Apache in LibreLAMP is patched to make the default minimum 3072-bit. When it comes to web servers, it is my opinion theDH parameter size issue is moot. Every client capable of TLS 1.2 supports ECDSA certificates so they should be used, making ECDHE cipher suites the only option. Even if you use an RSA certificate, ECDHE cipher suites are supported by every modern web client and many outdated clients. There just is not a reason to enable DHE cipher suites in a web server.
4.2.3. Cipher Choice From the list of cipher suites shown on page 26 we can see there are only two cipher families worth considering: ChaCha and AES.
ChaCha20 ChaCha is a family of ciphers created by Daniel J. Bernstein7 (often referred to as just ‘djb’ in cryptography circles) based on Salsa20, which he also created. The ChaCha20 cipher was first standardized for use in TLS in RFC 75398, obsoleted by RFC 84399. It is not likely the other members of the ChaCha family will be standardized for TLS use. The other members use fewer rounds making them much faster but are really only intended where performance is valued enough to sacrifice some confidence. That is not the case with TLS. ChaCha20 is modern and very fast, often three times as fast as AES on platforms that do not have AES New Instruction (AES-NI) hardware acceleration. This is a tremendous benefit to mobile platforms. Poly1305 (also designed by dbj) is the MAC used with ChaCha20 in TLS. ChaCha20 always uses a 256-bit block. This should be top cipher suite of choice. Note that is not available in the crusty version of OpenSSL that ships with CentOS 7, but it is available in LibreSSL and LibreLAMP. This should be the first cipher suite offered by your server. To offer just this cipher suite, your cipher spec would look like this:
6https://weakdh.org/ 7https://cr.yp.to/djb.html 8https://tools.ietf.org/html/rfc7539 9https://tools.ietf.org/html/rfc8439
27 4. Apache and TLS (SSL)
1 SSLCipherSuite "EECDH+CHACHA20"
Note that with ECDSA certificates the EECDH is redundant and can be left off, but it does not hurt to have it there. With RSA certificates, if you leave out the EECDH then other Key Exchange variants of the cipher suite will also be available, and with some cipher families, that includes cipher suites that do not use forward secrecy. So always include the key exchange in a cipher spec rule set, even with ECDSA certificates, so that if another admin renews the server certificate with an RSA certificate it does not result in unsafe key exchange cipher suites being available. At this time, there are still many browsers that do not support the CHACHA20-POLY1305 cipher suites (or in the case of the Android 6 browser, only support the older version defined in RFC 7539 that has been rendered obsolete by RFC 8439). So we will need to add at least one AES cipher suite to our cipher spec.
Advanced Encryption Standard (AES) Long considered the ‘gold standard’ of encryption, AES was created by Vincent Rijmen10 and Joan Daemon11. AES is actually a subset of the Rijndael family of block ciphers, with the National Institute of Standards and Technology (NIST) selecting the 128, 192, and 256 bit block size variants for the AES standard. At this point, AES support is virtually ubiquitous. Some hardware platforms (such as XEON processors) have hardware accelerated instruction sets that radically speed up the performance of AES.
4.2.4. Authenticated Encryption with Associated Data (AEAD) AEAD is an easy to use programming interface for providing simultaneous assurance of both the confidentiality and authentication of the data. The proper implementation of cryptography is hard. The slightest programming mistake in the implementation and the implementation is vulnerable to an attack even if the cipher itself is a solid secure cipher. For example, in addition to a secret key, ciphers use a nonce. The nonce does not need to be secret, but it does really need to be used only once or the attacker can figure out the secret and defeat the encryption. The AEAD programming interface makes it a lot easier for programmers to get the implemen- tation right and avoid many of the issues. AEAD is an implementation of the KISS concept I mentioned earlier.
10http://www.iaik.tugraz.at/content/about_iaik/people/alumni_rijmen_vincent/ 11https://cs.ru.nl/˜joan/
28 4. Apache and TLS (SSL)
TLS 1.3 only allows cipher suites that use AEAD. This includes ChaCha20-poly1305 but only includes the AES cipher suites that use Galois/Counter Mode (GCM). To add support for all AES cipher suites that use GCM our cipher spec now will look like this:
1 SSLCipherSuite "EECDH+CHACHA20 EECDH+AESGCM"
With that cipher spec, in LibreLAMP the following three ciphers will be supported:
1. ECDHE-certificate type-CHACHA20-POLY1305
2. ECDHE-certificate type-AES256-GCM-SHA384
3. ECDHE-certificate type-AES128-GCM-SHA256
Note that certificate type means ECDSA if you have a ECDSA server certificate, and it means RSA if you have a RSA server certificate. That covers support for every modern browser.
Safari 8 Safari 8 is an older browser that is not supported by the ciphers in that list. Safari 8 does not support any cipher suites that implement AEAD. I do not know how common Safari 8 still is. If you must support Safari 8, add EECDH+AES256+SHA384 so the cipher spec will now look like this:
1 SSLCipherSuite "EECDH+CHACHA20 EECDH+AESGCM EECDH+AES256+SHA384"
With that cipher spec in LibreLAMP, the supported cipher list will now contain:
1. ECDHE-certificate type-CHACHA20-POLY1305
2. ECDHE-certificate type-AES256-GCM-SHA384
3. ECDHE-certificate type-AES128-GCM-SHA256
4. ECDHE-certificate type-AES256-SHA384
The added cipher suite is a Cipher Block Chaining (CBC) cipher suite. For some reason Apple really liked CBC ciphers, but implementation mistakes frequently result in vulnerability to what is called a Padding Oracle Attack12. Do not support Safari 8 unless you really need to.
12https://en.wikipedia.org/wiki/Padding_oracle_attack
29 4. Apache and TLS (SSL)
4.2.5. Cipher Block Size Many system administrators recommend only using cipher suites that use at least 256 bits for the block size. However you should be aware I have seen cryptographers I trust rebuke that requirement as lacking academic justification. There is some U.S. government document somewhere stating that encryption for ‘Top Secret’ classified documents must use 256-bit encryption and I believe that is where the notion some system administrators have comes from. See AppendixA on page 35 for an explanation as to why I do not believe 128-bit block ciphers are inherently unsafe. If you really want to exclude the 128-bit cipher, add -AES128 to the cipher spec so that it looks like this:
1 SSLCipherSuite "EECDH+CHACHA20 EECDH+AESGCM -AES128"
That will filter out the ECDHE-certificate type-AES128-GCM-SHA256 cipher suite. The consequence of making that change, the default browser in Android 6 will no longer be supported. Even though Android 6 is old, many lower income people including myself are stuck with older phones running Android 6 that can not be updated to a newer version of Android. One of the principles of security I stated near the beginning of section 4.2 (on page 23) is ‘Less is More’ – do not support cipher suites you do not need to support. Well, do not exclude users you do not need to exclude just because they are poor. That is called classism. Classism is not a security problem, but it is an asshole problem. With Safari 8, Apple provides iOS updates to older phones and the cipher needed to support Safari 8 is not an AEAD cipher so there are legitimate security concerns. However with Android, whether OS updates are made available on a still-supported phone is up to the device manufacturer and many choose not to do so. They often want us to dispose of perfectly working phones and buy new phones to get Android updates. Capitalism at its finest. Increase electronic waste when there isn’t a technical need. Android 6 only supports two 256-bit cipher families. One uses the deprecated variant of ChaCha20 that is no longer supported in TLS libraries and the other is not an AEAD suite and furthermore it uses an insecture SHA MAC. 128-bit AES with GCM is better than that option. Android 6 users can use FireFox for Android which supports better cipher-suites, but many use the default browser.
4.2.6. Alice’s Recommended Cipher Spec This is the cipher spec I currently use in the vast majority of my virtual hosts:
1 SSLHonorCipherOrder on 2 SSLCipherSuite "EECDH+CHACHA20 EECDH+AESGCM"
30 4. Apache and TLS (SSL)
If you must still support Safari 8, use the following:
1 SSLHonorCipherOrder on 2 SSLCipherSuite "EECDH+CHACHA20 EECDH+AESGCM EECDH+AES256+SHA384"
If you do not care about Android 6, use the following:
1 SSLHonorCipherOrder on 2 SSLCipherSuite "EECDH+CHACHA20 EECDH+AESGCM -AES128"
Enforce Cipher Order By default, TLS 1.2 allows the client to select the cipher suite used from what is offered. This is not ideal as it potentially allows an attacker to trick the session into using a cipher suite that is easier for them to attack. Always require that the cipher used is the first cipher in the list resulting from your cipher spec that the client supports. You can do this with the following directive:
1 SSLHonorCipherOrder on
Clients that support ECDHE-ECDSA-CHACHA20-POLY1305 will use that cipher suite. Clients that not support that cipher suite but do support ECDHE-ECDSA-AES256-GCM-SHA384 will in- stead use that one. After configuring your cipher spec, and periodically afterwards, test you server using SSL Labs13 to see any reported security flaws.
4.3. Strict Transport Security
When the World Wide Web and the HTTP was first invented in 1990 it did not include any mech- anisms for security. Responses to a request may be modified by an attacker and the web browser will make the assumption that it is valid. Even if all your content is served with TLS, an attacker can take advantage of this historic weakness by sending the user a link to your web site using http:// instead of https://. The domain name will look correct to the user, so the user will often trust that it is okay and become a victim. The response from your server redirecting the victim to your secure site can then be modified by the attacker to instead redirect to a site they control. To help mitigate this attact, HTTP Strict Transport Security (HSTS) was defined in RFC 679714.
13https://www.ssllabs.com/ 14https://tools.ietf.org/html/rfc6797
31 4. Apache and TLS (SSL)
This is a header your browser should send to a requesting client whenever it connects so that the client knows to always connect to the TLS protected https:// version of your web site even if the Uniform Resource Locator (URL) specifies http://. To implement HSTS in your secure Apache web server, add the following directive (or some- thing very similar) to all your virtual hosts on Port 443. The first parameter is required. The others are optional and when present, the parameter that precedes it should be followed by a semi-colon.
1 Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains"
4.3.1. The max-age Parameter This parameter is required. It tells the client how long to remember that it should only use a secure TLS connection to your web site. The number is the number of seconds the client should remember this for and should at a minimum be set to 60 days (5184000 seconds). I personally set it to 2 years (63072000 seconds).
4.3.2. The Optional includeSubdomains Parameter This is a boolean parameter and does not take any arguments. If present, the client will apply HSTS to all sub-domains even if the client has not visited those sub-domains. I highly recommend you use this parameter, though there are a few legitimate reasons not to.
4.3.3. The Optional preload Parameter When a client has not visited your website before, it has never received the HSTS header and does not know that it should only use TLS and is thus still vulnerable to attack. What you can do to mitigate that scenario is get your domain added to domains that browser vendors know they should always apply the HSTS rules to. Note that use of this parameter requires use of the previously mentioned includeSubdomains parameter or it is ignored. The Apache directive after adding this boolean parameter will look something like this:
1 Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"
Once that is done, you have to request that browsers include your domain in their list. You do this at the HSTS Preload List Submission15 web site. The submission site will check that everything is in order and report any errors to you. If everything is in order, a person will review the request and add it to the list of domains that major browser vendors hard-code in the browser software itself to always apply the HSTS rules to.
15https://hstspreload.org/
32 4. Apache and TLS (SSL)
Once you are listed, updates to the major browsers will include your domain and even users who have never visited your web site will be protectd from the attack vector.
4.4. TLDR Nutshell Bullet List
• With modern TLS the only purpose of the server certificate is to provide authentication to the client during the key exchange.
• With a very few exceptions, ECDSA server X.509 certificates should be chosen over RSA.
• Always configure your TLS virtual hosts to honor the selected cipher order.
• Only use cipher suites that use aFS key exchange.
• When using DHE for the key exchange, make sure yourDH parameters are at least 2048-bit.
• Only use AEAD cipher suites.
• Shorter cipher suite lists are easier to manage.
33 Part II.
General Appendices
34 A. 128-bit Block Ciphers
This is my opinion. I came close to a BA in Mathematics but was forced to drop out due to economics. If an actual academic cryptographer with papers in respected peer reviewed journals says otherwise, her or his advice is probably better than mine, though keep in mind some respected academics go quackers — like the respected physicist who now believes he has mathematical proof of God. However, when some random web page or ‘security expert’ tells you not to use cipher suites with less than 256 bit blocks, also consider the source. Do they do academic research? What gives their advice actual academic authority? I do personally prefer 256-bit block ciphers, just like I prefer organic milk (but still pasteurized). But I will allow 128-bit ciphers when the client needs it, just like I usually drink the less expensive non-organic milk I can actually afford. Table A.1 is why I do not consider 128-bit blocks to be unsafe.
Table A.1.: Exponential Growth Power of Two Decimal Equivalent 20 1 21 2 22 4 24 16 28 256 216 65536 232 4294967296 264 1:844674407 1019 280 1:208925820 1024 2128 3:402823669 1028 2160 1:461501637 1048 (Bitcoin private key level of security1) 2256 1:157920892 1077 (Most modern ciphers) 2320 2:135987036 1092 2512 1:340780793 10154
It is estimated there are 1024 stars in the known universe.
1keys are 256-bit but involve a RIPEMD160 hash
35 A. 128-bit Block Ciphers
While time is relative so I am not sure what this number actually means, it is estimated the age of the known universe is 4:36 1023 micro-senconds. What I am trying to impress upon you is that 2128 is a very very very big number. When a cipher-suite does not have an algorithm flaw, an attack on the encryption must be done with brute force, trying each combination used to decipher a block until it works. The number of possible combinations used to encipher a block of data grows exponentially as the block size grows. While it is possible to brute-force an 80-bit cipher with today’s hardware, it would take an incredible amount of computing power and time. A 128-bit cipher has significantly more possible combinations (remember that even 81-bit has twice as many combinations as 80). It is doubtful that 128-bit ciphers will be susceptible to a brute force attack without quantum computing during our lifetime. Attacks on 128-bit cipher-suites (or even 80-bit for that matter) are not going to use brute force. They are going to look for other weaknesses in the cipher suite. This is whyFS and AEAD are more important than the cipher block size. Do not allow 80-bit ciphers, but it would likely take the equivalent of a year’s worth of bitcoin mining to brute-force but it can be done. Anyone with enough computing power to brute force a 128-bit cipher would easily be able to pull a 51% attack2 on Bitcoin. If it were possible, it would have been done. It is only my opinion that it is ignorance to consider 128-bit block ciphers to be insecure, but I challenge anyone to come up with actual evidence that 128-bit blocks are not safe. When quantum computing becomes a reality, 128-bit ciphers will not be safe, but if quantum computing is your concern, do not be so confident the 256-bit ciphers will be safe either.
2https://www.fxempire.com/education/article/51-attack-explained-the-attack-on-a-blockchain-513887
36 Part III.
Licenses
37 GNU Free Documentation License
Version 1.3, 3 November 2008 Copyright © 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
Preamble
The purpose of this License is to make a manual, textbook, or other functional and useful doc- ument “free” in the sense of freedom: to assure everyone the effective freedom to copy and redis- tribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others. This License is a kind of “copyleft”, which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software. We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.
1. APPLICABILITY AND DEFINITIONS
This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the condi- tions stated herein. The “Document”, below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as “you”. You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law. A“Modified Version” of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language. A“Secondary Section” is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document’s
38 overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them. The “Invariant Sections” are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none. The “Cover Texts” are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words. A“Transparent” copy of the Document means a machine-readable copy, represented in a for- mat whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint pro- grams or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not “Transparent” is called “Opaque”. Examples of suitable formats for Transparent copies include plain ASCII without markup, Tex- info input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Exam- ples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only. The “Title Page” means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, “Title Page” means the text near the most prominent appearance of the work’s title, preceding the beginning of the body of the text. The “publisher” means any person or entity that distributes copies of the Document to the public. A section “Entitled XYZ” means a named subunit of the Document whose title either is pre- cisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as “Acknowledgements”, “Dedications”, “Endorsements”, or “History”.) To “Preserve the Title” of such a section when you modify the Document means that it remains a section “Entitled XYZ” according to this defini- tion. The Document may include Warranty Disclaimers next to the notice which states that this Li-
39 cense applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.
2. VERBATIM COPYING
You may copy and distribute the Document in any medium, either commercially or noncommer- cially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatso- ever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3. You may also lend copies, under the same conditions stated above, and you may publicly display copies.
3. COPYING IN QUANTITY
If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document’s license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front- Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects. If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages. If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public. It is requested, but not required, that you contact the authors of the Document well before redis- tributing any large number of copies, to give them a chance to provide you with an updated version of the Document.
4. MODIFICATIONS
40 You may copy and distribute a Modified Version of the Document under the conditions of sec- tions 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modifi- cation of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:
A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.
B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement.
C. State on the Title page the name of the publisher of the Modified Version, as the publisher.
D. Preserve all the copyright notices of the Document.
E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.
F. Include, immediately after the copyright notices, a license notice giving the public permis- sion to use the Modified Version under the terms of this License, in the form shown in the Addendum below.
G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document’s license notice.
H. Include an unaltered copy of this License.
I. Preserve the section Entitled “History”, Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled “History” in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.
J. Preserve the network location, if any, given in the Document for public access to a Trans- parent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the “History” section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.
41 K. For any section Entitled “Acknowledgements” or “Dedications”, Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.
L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.
M. Delete any section Entitled “Endorsements”. Such a section may not be included in the Modified Version.
N. Do not retitle any existing section to be Entitled “Endorsements” or to conflict in title with any Invariant Section.
O. Preserve any Warranty Disclaimers.
If the Modified Version includes new front-matter sections or appendices that qualify as Sec- ondary Sections and contain no material copied from the Document, you may at your option des- ignate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version’s license notice. These titles must be distinct from any other section titles. You may add a section Entitled “Endorsements”, provided it contains nothing but endorsements of your Modified Version by various parties—for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard. You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one. The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.
5. COMBINING DOCUMENTS
You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combi- nation all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers. The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of
42 it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work. In the combination, you must combine any sections Entitled “History” in the various original documents, forming one section Entitled “History”; likewise combine any sections Entitled “Ac- knowledgements”, and any sections Entitled “Dedications”. You must delete all sections Entitled “Endorsements”.
6. COLLECTIONS OF DOCUMENTS
You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects. You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.
7. AGGREGATION WITH INDEPENDENT WORKS
A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an “aggregate” if the copyright resulting from the compilation is not used to limit the legal rights of the compilation’s users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document. If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document’s Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.
8. TRANSLATION
Translation is considered a kind of modification, so you may distribute translations of the Doc- ument under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a trans- lation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.
43 If a section in the Document is Entitled “Acknowledgements”, “Dedications”, or “History”, the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title. 9. TERMINATION
You may not copy, modify, sublicense, or distribute the Document except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, or distribute it is void, and will automatically terminate your rights under this License. However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation. Moreover, your license from a particular copyright holder is reinstated permanently if the copy- right holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice. Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you under this License. If your rights have been terminated and not permanently reinstated, receipt of a copy of some or all of the same material does not give you any rights to use it. 10. FUTURE REVISIONS OF THIS LICENSE
The Free Software Foundation may publish new, revised versions of the GNU Free Documenta- tion License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See https://www.gnu.org/licenses/. Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License “or any later version” applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation. If the Document specifies that a proxy can decide which future versions of this License can be used, that proxy’s public statement of acceptance of a version permanently authorizes you to choose that version for the Document. 11. RELICENSING
“Massive Multiauthor Collaboration Site” (or “MMC Site”) means any World Wide Web server that publishes copyrightable works and also provides prominent facilities for anybody to edit those works. A public wiki that anybody can edit is an example of such a server. A “Massive Multiau- thor Collaboration” (or “MMC”) contained in the site means any set of copyrightable works thus published on the MMC site.
44 “CC-BY-SA” means the Creative Commons Attribution-Share Alike 3.0 license published by Creative Commons Corporation, a not-for-profit corporation with a principal place of business in San Francisco, California, as well as future copyleft versions of that license published by that same organization. “Incorporate” means to publish or republish a Document, in whole or in part, as part of another Document. An MMC is “eligible for relicensing” if it is licensed under this License, and if all works that were first published under this License somewhere other than this MMC, and subsequently incor- porated in whole or in part into the MMC, (1) had no cover texts or invariant sections, and (2) were thus incorporated prior to November 1, 2008. The operator of an MMC Site may republish an MMC contained in the site under CC-BY-SA on the same site at any time before August 1, 2009, provided the MMC is eligible for relicensing.
ADDENDUM: How to use this License for your documents
To use this License in a document you have written, include a copy of the License in the docu- ment and put the following copyright and license notices just after the title page:
Copyright © YEAR YOUR NAME. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Ver- sion 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled “GNU Free Documentation License”.
If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the “with . . . Texts.” line with this:
with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation. If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.
45 Dual OpenSSL and SSLeay License
NOTE: Original license text ported to LATEX for inclusion in this book. The unmodified text file can be obtained at:
https://www.openssl.org/source/license-openssl-ssleay.txt
LICENSE ISSUES
The OpenSSL toolkit stays under a double license, i.e. both the conditions of the OpenSSL License and the original SSLeay license apply to the toolkit. See below for the actual license texts.
OpenSSL License
Copyright © 1998–2018 The OpenSSL Project. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of con- ditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software must display the follow- ing acknowledgment: “This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)”
4. The names “OpenSSL Toolkit” and “OpenSSL Project” must not be used to endorse or pro- mote products derived from this software without prior written permission. For written per- mission, please contact [email protected].
5. Products derived from this software may not be called “OpenSSL” nor may “OpenSSL” appear in their names without prior written permission of the OpenSSL Project.
46 6. Redistributions of any form whatsoever must retain the following acknowledgment: “This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/)”
THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT “AS IS” AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIM- ITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FIT- NESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DI- RECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUEN- TIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,WHETHER IN CONTRACT, STRICT LIABILITY,OR TORT (INCLUD- ING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
This product includes cryptographic software written by Eric Young ([email protected]). This product includes software written by Tim Hudson ([email protected]).
Original SSLeay License
Copyright ©1995–1998 Eric Young ([email protected]) All rights reserved. This package is an SSL implementation written by Eric Young ([email protected]). The im- plementation was written so as to conform with Netscapes SSL. This library is free for commercial and non-commercial use as long as the following conditions are aheared to. The following conditions apply to all code found in this distribution, be it the RC4, RSA, lhash, DES, etc., code; not just the SSL code. The SSL documentation included with this distribution is covered by the same copyright terms except that the holder is Tim Hudson ([email protected]). Copyright remains Eric Young’s, and as such any Copyright notices in the code are not to be removed. If this package is used in a product, Eric Young should be given attribution as the author of the parts of the library used. This can be in the form of a textual message at program startup or in documentation (online or textual) provided with the package. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the copyright notice, this list of conditions and the following disclaimer.
47 2. Redistributions in binary form must reproduce the above copyright notice, this list of con- ditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software must display the fol- lowing acknowledgement: “This product includes cryptographic software written by Eric Young ([email protected])” The word ’cryptographic’ can be left out if the rouines from the library being used are not cryptographic related :-).
4. If you include any Windows specific code (or a derivative thereof) from the apps directory (application code) you must include an acknowledgement: “This product includes software written by Tim Hudson ([email protected])”
THIS SOFTWARE IS PROVIDED BY ERIC YOUNG “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IM- PLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTIC- ULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOW- EVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CON- TRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTH- ERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
The licence and distribution terms for any publically available version or derivative of this code cannot be changed. i.e. this code cannot simply be copied and put under another distribution licence [including the GNU Public Licence.]
48 Apache 2.0 License
NOTE: Original license text ported to LATEX for inclusion in this book. The official license can be obtained at:
https://www.apache.org/licenses/LICENSE-2.0
Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
1. Definitions
“License” shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document. “Licensor” shall mean the copyright owner or entity authorized by the copyright owner that is granting the License. “Legal Entity” shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, “control” means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. “You” (or “Your”) shall mean an individual or Legal Entity exercising permissions granted by this License. “Source” form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files. “Object” form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types.
49 “Work” shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below). “Derivative Works” shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. “Contribution” shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this def- inition, “submitted” means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as “Not a Contribution.” “Contributor” shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work.
2. Grant of Copyright License
Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to re- produce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form.
3. Grant of Patent License
Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribu- tion(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.
4. Redistribution
50 You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:
(a) You must give any other recipients of the Work or Derivative Works a copy of this License; and
(b) You must cause any modified files to carry prominent notices stating that You changed the files; and
(c) You must retain, in the Source form of any Derivative Works that You distribute, all copy- right, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and
(d) If the Work includes a “NOTICE” text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file dis- tributed as part of the Derivative Works; within the Source form or documentation, if pro- vided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NO- TICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.
You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.
5. Submission of Contributions
Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.
6. Trademarks
This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.
51 7. Disclaimer of Warranty
Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permis- sions under this License.
8. Limitation of Liability
In no event and under no legal theory, whether in tort (including negligence), contract, or oth- erwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of good- will, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages.
9. Accepting Warranty or Additional Liability
While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability.
END OF TERMS AND CONDITIONS
52 APPENDIX: How to apply the Apache License to your work
To apply the Apache License to your work, attach the following boilerplate notice, with the fields enclosed by brackets “[]” replaced with your own identifying information. (Don’t include the brackets!) The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same “printed page” as the copyright notice for easier identification within third-party archives.
Copyright [yyyy] [name of copyright owner]
Licensed under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance with the License. You may obtain a copy of the License at
https://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed un- der the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
53 GNU GENERAL PUBLIC LICENSE
Version 2, June 1991 Copyright © 1989, 1991 Free Software Foundation, Inc.
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
Preamble
The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software—to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation’s software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too. When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things. To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it. For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software. Also, for each author’s protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors’ reputations. Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making
54 the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone’s free use or not licensed at all. The precise terms and conditions for copying, distribution and modification follow.
TERMSAND CONDITIONS FOR COPYING,DISTRIBUTIONAND MODIFICATION
0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The “Program”, below, refers to any such program or work, and a “work based on the Pro- gram” means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term “modification”.) Each licensee is addressed as “you”. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.
1. You may copy and distribute verbatim copies of the Program’s source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.
2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy
55 of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work writ- ten entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, c) Accompany it with the information you received as to the offer to distribute correspond- ing source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all mod- ules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or bi- nary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
56 If distribution of executable or object code is made by offering access to copy from a des- ignated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code. 4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your accep- tance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it. 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients’ exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. 7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program. If any portion of this section is held invalid or unenforceable under any particular circum- stance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.
57 This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.
9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and “any later version”, you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.
10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of pre- serving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.
NO WARRANTY
11.B ECAUSETHEPROGRAMISLICENSEDFREEOFCHARGE, THERE IS NO WARRANTY FOR THEPROGRAM, TOTHEEXTENTPERMITTEDBYAPPLICABLELAW.EXCEPTWHENOTH- ERWISESTATEDINWRITINGTHECOPYRIGHTHOLDERSAND/OR OTHER PARTIES PRO- VIDETHEPROGRAM “ASIS” WITHOUTWARRANTYOFANYKIND, EITHEREXPRESSED ORIMPLIED, INCLUDING, BUTNOTLIMITEDTO, THEIMPLIEDWARRANTIESOFMER- CHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.THEENTIRERISKASTO THEQUALITYANDPERFORMANCEOFTHEPROGRAMISWITHYOU.SHOULDTHEPRO- GRAMPROVEDEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, RE- PAIR OR CORRECTION.
12.I NNOEVENTUNLESSREQUIREDBYAPPLICABLELAWORAGREEDTOINWRITING WILLANYCOPYRIGHTHOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTETHEPROGRAMASPERMITTEDABOVE, BELIABLETOYOUFORDAM- AGES, INCLUDINGANYGENERAL, SPECIAL, INCIDENTALORCONSEQUENTIALDAM- AGESARISINGOUTOFTHEUSEORINABILITYTOUSETHEPROGRAM (INCLUDINGBUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES
58 SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITHANYOTHERPROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISEDOFTHEPOSSIBILITYOFSUCHDAMAGES.
ENDOF TERMSAND CONDITIONS
59 Appendix: How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms. To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the “copyright” line and a pointer to where the full notice is found.
one line to give the program’s name and a brief idea of what it does. Copyright (C) yyyy name of author
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FIT- NESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
Also add information on how to contact you by electronic and paper mail. If the program is interactive, make it output a short notice like this when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) yyyy name of author Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type ‘show w’. This is free software, and you are welcome to redistribute it under certain conditions; type ‘show c’ for details.
The hypothetical commands ‘show w’ and ‘show c’ should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than ‘show w’ and ‘show c’; they could even be mouse-clicks or menu items—whatever suits your program. You should also get your employer (if you work as a programmer) or your school, if any, to sign a “copyright disclaimer” for the program, if necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the program ‘Gnomovision’ (which makes passes at compilers) written by James Hacker.
60 signature of Ty Coon, 1 April 1989 Ty Coon, President of Vice
This General Public License does not permit incorporating your program into proprietary pro- grams. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License.
61 GNU LESSER GENERAL PUBLIC LICENSE
Version 2.1, February 1999 Copyright © 1991, 1999 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.
Preamble
The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software–to make sure the software is free for all its users. This license, the Lesser General Public License, applies to some specially designated software packages–typically libraries–of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things. To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library. To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know
62 that what they have is not the original version, so that the original author’s reputation will not be affected by problems that might be introduced by others. Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. Most GNU software, including some libraries, is covered by the ordinary GNU General Pub- lic License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. When a program is linked with a library, whether statically or using a shared library, the com- bination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library. We call this license the “Lesser” General Public License because it does Less to protect the user’s freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances. For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. Although the Lesser General Public License is Less protective of the users’ freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library. The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a “work based on the library” and a “work that uses the library”. The former contains code derived from the library, whereas the latter must be combined with the library in order to run.
TERMSAND CONDITIONS FOR COPYING,DISTRIBUTIONAND MODIFICATION
0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed
63 under the terms of this Lesser General Public License (also called “this License”). Each licensee is addressed as “you”. A “library” means a collection of software functions and/or data prepared so as to be con- veniently linked with application programs (which use some of those functions and data) to form executables. The “Library”, below, refers to any such software library or work which has been distributed under these terms. A “work based on the Library” means either the Library or any deriva- tive work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term “modification”.) “Source code” for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does.
1. You may copy and distribute verbatim copies of the Library’s complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.
2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the
64 event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work writ- ten entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library. In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library.
4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the
65 requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a “work that uses the Library”. Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a “work that uses the Library” with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a “work that uses the library”. The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a “work that uses the Library” uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. 6. As an exception to the Sections above, you may also combine or link a “work that uses the Library” with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer’s own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable “work that uses the Library”, as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.)
66 b) Use a suitable shared library mechanism for linking with the Library. A suitable mech- anism is one that (1) uses at run time a copy of the library already present on the user’s computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. For an executable, the required form of the “work that uses the Library” must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute.
7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work.
8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
67 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it. 10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients’ exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License. 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. If any portion of this section is held invalid or unenforceable under any particular circum- stance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 13. The Free Software Foundation may publish revised and/or new versions of the Lesser Gen- eral Public License from time to time. Such new versions will be similar in spirit to the
68 present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and “any later version”, you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation.
14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For soft- ware which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.
NO WARRANTY
15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WAR- RANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIM- ITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PER- FORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DE- FECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LI- ABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDEN- TAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABIL- ITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
ENDOF TERMSAND CONDITIONS
69 How to Apply These Terms to Your New Libraries
If you develop a new library, and you want it to be of the greatest possible use to the public, we recommend making it free software that everyone can redistribute and change. You can do so by permitting redistribution under these terms (or, alternatively, under the terms of the ordinary General Public License). To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the “copyright” line and a pointer to where the full notice is found.
one line to give the library’s name and an idea of what it does. Copyright (C) year name of author This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WAR- RANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Also add information on how to contact you by electronic and paper mail. You should also get your employer (if you work as a programmer) or your school, if any, to sign a “copyright disclaimer” for the library, if necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the library ‘Frob’ (a library for tweaking knobs) written by James Random Hacker. signature of Ty Coon, 1 April 1990 Ty Coon, President of Vice
That’s all there is to it!
70 The PHP License, version 3.01
NOTE: Original license text ported to LATEX for inclusion in this book. The official license can be obtained at:
https://www.php.net/license/3 01.txt
The PHP License, version 3.01
Copyright © 1999 – 2019 The PHP Group. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, is permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of con- ditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
3. The name ”PHP” must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact [email protected].
4. Products derived from this software may not be called “PHP”, nor may “PHP” appear in their name, without prior written permission from [email protected]. You may indicate that your software works in conjunction with PHP by saying “Foo for PHP” instead of calling it “PHP Foo” or “phpfoo”
5. The PHP Group may publish revised and/or new versions of the license from time to time. Each version will be given a distinguishing version number. Once covered code has been published under a particular version of the license, you may always continue to use it under the terms of that version. You may also choose to use such covered code under the terms of any subsequent version of the license published by the PHP Group. No one other than the PHP Group has the right to modify the terms applicable to covered code created under this License.
71 6. Redistributions of any form whatsoever must retain the following acknowledgment: “This product includes PHP software, freely available from
THISSOFTWAREISPROVIDEDBY THE PHPDEVELOPMENT TEAM “AS IS” ANDANY EXPRESSEDORIMPLIEDWARRANTIEC, INCLUDING, BUTNOTLIMITEDTO, THEIMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DIS- CLAIMED.INNOEVENTSHALL THE PHPDEVELOPMENT TEAMORITSCONTRIBUTORSBE LIABLEFORANYDIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, ORCONSEQUEN- TIALDAMAGES (INCLUDING, BUTNOTLIMITEDTO, PROCUREMENTOFSUBSTITUTEGOODS OR SERVICES; LOSSOFUSE, DATA, OR PROFITS; ORBUSINESSINTERRUPTION) HOWEVER CAUSEDANDONANYTHEORYOFLIABILITY, WHETHERINCONTRACT, STRICTLIABILITY, OR TORT (INCLUDINGNEGLIGENCEOROTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVENIFADVISEDOFTHEPOSSIBILITYOFSUCHDAMAGE.
This software consists of voluntary contributions made by many individuals on behalf of the PHP Group. The PHP Group can be contacted via Email at [email protected]. For more information on the PHP Group and the PHP project, please see
72 Part IV.
Man Pages
73 Man Page Notes
The following man pages are either from software packaged in LibreLAMP or from software pack- aged in CentOS 7 / EPEL. These man pages were manually ported to LATEX source .tex files and may not represent the most current version. Manual conversion may mean human errors in the ports exist, but I have found the results are usually better than automated conversions. To view the current version, please use the man command on an up to date system.
LibreSSL Notes
CentOS 7 ships with OpenSSL. LibreLAMP adds LibreSSL but leaves the system installed OpenSSL alone. LibreSSL is a fork of OpenSSL that maintains the same command names in the upstream LibreSSL project. To avoid confusion and file conflicts, LibreLAMP renames the openssl command from the LibreSSL fork to libressl. Furthermore the openssl.1 man page from LibreSSL has been renamed to libressl.1 in LibreLAMP and the openssl.cnf.5 man page from LibreSSL has been renamed to libressl.cnf.5 in LibreLAMP.
74 B. LibreSSL configuration files
B.1. DESCRIPTION
The OpenSSL CONF library can be used to read configuration files; see CONF modules load file(3). It is used for the OpenSSL master configuration file /etc/pki/tls/libressl.cnf and in a few other places like SPKAC files and certificate extension files for the openssl(1) x509 utility. OpenSSL applications can also use the CONF library for their own purposes. A configuration file is divided into a number of sections. Each section starts with a line [section name] and ends when a new section is started or the end of the file is reached. A section name can consist of alphanumeric characters and underscores. The first section of a configuration file is special and is referred to as the “default section”. It is usually unnamed and extends from the start of file to the first named section. When a name is being looked up, it is first looked up in a named section (if any) and then in the default section. The environment is mapped onto a section called ENV. Comments can be included by preceding them with the ‘#’ character. Each section in a configuration file consists of a number of name and value pairs of the form name=value. The name string can contain any alphanumeric characters as well as a few punctuation symbols such as ‘.’‘,’‘;’ and ‘ ’. The value string consists of the string following the ‘=’ character until the end of the line with any leading and trailing whitespace removed. The value string undergoes variable expansion. This can be done by including substrings of the form $name or ${name}: this will substitute the value of the named variable in the current section. It is also possible to substitute a value from another section using the syntax $section::name or ${section::name}. By using the form $ENV::name, environment variables can be substituted. It is also possible to assign values to environment variables by using the name ENV::name. This will work if the program looks up environment variables using the CONF library instead of calling getenv(3) directly. It is possible to escape certain characters by using any kind of quote or the ‘ ’ character. By n making the last character of a line a ‘ ’, a value string can be spread across multiple lines. In n addition the sequences ‘ n’, ‘ r’, ‘ b’, and ‘ t’, are recognized. n n n n
75 B. LibreSSL configuration files
B.2. OPENSSL LIBRARY CONFIGURATION
Applications can automatically configure certain aspects of OpenSSL using the master OpenSSL configuration file, or optionally an alternative configuration file. The libressl utility includes this functionality: any sub command uses the master OpenSSL configuration file unless an option is used in the sub command to use an alternative configuration file. To enable library configuration, the default section needs to contain an appropriate line which points to the main configuration section. The default name is openssl conf, which is used by the libressl utility. Other applications may use an alternative name such as myapplica- tion conf. All library configuration lines appear in the default section at the start of the configu- ration file. The configuration section should consist of a set of name value pairs which contain specific module configuration information. The name represents the name of the configuration module. The meaning of the value is module specific: it may, for example, represent a further configuration section containing configuration module specific information. For example:
# The following line must be in the default section. openssl_conf = openssl_init
[openssl_init] oid_section = new_oids engines = engine_section
[new_oids] ... new oids here ...
[engine_section] ... engine stuff here ...
The features of each configuration module are described below.
B.2.1. ASN1 Object Configuration Module This module has the name oid section. The value of this variable points to a section containing name value pairs of OIDs: the name is the Object Identifier (OID) short and long name, and the value is the numerical form of the OID. Although some of the libressl utility subcommands al- ready have their own ASN1 OBJECT section functionality, not all do. By using the ASN1 OBJECT configuration module, all the libressl utility subcommands can see the new objects as well as any compliant applications. For example:
[new_oids] some_new_oid = 1.2.3.4 some_other_oid = 1.2.3.5
76 B. LibreSSL configuration files
It is also possible to set the value to the long name followed by a comma and the numerical OID form. For example:
shortName = some object long name, 1.2.3.4
B.2.2. Engine Configuration Module This ENGINE configuration module has the name engines. The value of this variable points to a section containing further ENGINE configuration information. The section pointed to by engines is a table of engine names (though see engine id below) and further sections containing configuration information specific to each ENGINE. Each ENGINE specific section is used to set default algorithms, load dynamic ENGINEs, perform initialization and send ctrls. The actual operation performed depends on the command name which is the name of the name value pair. The currently supported commands are listed below. For example:
[engine_section] # Configure ENGINE named "foo" foo = foo_section # Configure ENGINE named "bar" bar = bar_section
[foo_section] ... foo ENGINE specific commands ...
[bar_section] ... "bar" ENGINE specific commands ...
The command engine id is used to give the ENGINE name. If used this command must be first. For example:
[engine_section] # This would normally handle an ENGINE named "foo" foo = foo_section
[foo_section] # Override default name and use "myfoo" instead. engine_id = myfoo
The command dynamic path loads and adds an ENGINE from the given path. It is equivalent to sending the ctrls SO PATH with the path argument followed by LIST ADD with value 2 and LOAD to the dynamic ENGINE. If this is not the required behaviour then alternative ctrls can be sent directly to the dynamic ENGINE using ctrl commands. The command init determines whether to initialize the ENGINE. If the value is 0, the ENGINE will not be initialized. If it is 1, an attempt is made to initialized the ENGINE immediately. If
77 B. LibreSSL configuration files the init command is not present, then an attempt will be made to initialize the ENGINE after all commands in its section have been processed. The command default algorithms sets the default algorithms an ENGINE will supply using the functions ENGINE set default string(3). If the name matches none of the above command names it is assumed to be a ctrl command which is sent to the ENGINE. The value of the command is the argument to the ctrl command. If the value is the string EMPTY, then no value is sent to the command. For example:
[engine_section] # Configure ENGINE named "foo" foo = foo_section
[foo_section] # Load engine from DSO dynamic_path = /some/path/fooengine.so # A foo specific ctrl. some_ctrl = some_value # Another ctrl that doesn't take a value. other_ctrl = EMPTY # Supply all default algorithms default_algorithms = ALL
B.3. FILES
/etc/pki/tls/libressl.cnf standard configuration file
B.4. EXAMPLES
Here is a sample configuration file using some of the features mentioned above:
78 B. LibreSSL configuration files
# This is the default section. HOME=/temp RANDFILE= ${ENV::HOME}/.rnd configdir=$ENV::HOME/config
[ section_one ] # We are now in section one.
# Quotes permit leading and trailing whitespace any = " any variable name "
other = A string that can \e cover several lines \e by including \e\e characters
message = Hello World\en
[ section_two ] greeting = $section_one::message
This next example shows how to expand environment variables safely. Suppose you want a variable called tmpfile to refer to a temporary filename. The directory it is placed in can determined by the TEMP or TMP environment variables but they may not be set to any value at all. If you just include the environment variable names and the variable doesn’t exist then this will cause an error when an attempt is made to load the configuration file. By making use of the default section both values can be looked up with TEMP taking priority and /tmp used if neither is defined:
TMP=/tmp # The above value is used if TMP isn't in the environment TEMP=$ENV::TMP # The above value is used if TEMP isn't in the environment tmpfile=${ENV::TEMP}/tmp.filename
More complex OpenSSL library configuration. Add OID:
79 B. LibreSSL configuration files
# Default appname: should match "appname" parameter (if any) # supplied to CONF_modules_load_file et al. openssl_conf = openssl_conf_section
[openssl_conf_section] # Configuration module list alg_section = evp_sect oid_section = new_oids
[new_oids] # New OID, just short name newoid1 = 1.2.3.4.1 # New OID shortname and long name newoid2 = New OID 2 long name, 1.2.3.4.2
The above examples can be used with any application supporting library configuration if ‘openssl conf’ is modified to match the appropriate ‘appname’. For example if the second sample file above is saved to ‘example.cnf’ then the command line:
OPENSSL_CONF=example.cnf openssl asn1parse -genstr OID:1.2.3.4.1
will output:
0:d=0 hl=2 l= 4 prim: OBJECT :newoid1
showing that the OID‘ newoid1’ has been added as ‘1.2.3.4.1’.
B.5. SEE ALSO
• libressl(1)
• CONF modules load file(3)
• x509v3.cnf(5) (appendixC on page 83)
B.6. CAVEATS
If a configuration file attempts to expand a variable that doesn’t exist, then an error is flagged and the file will not load. This can also happen if an attempt is made to expand an environment variable that doesn’t exist. For example, in a previous version of OpenSSL the default OpenSSL master configuration file used the value of HOME which may not be defined on non UNIX systems and would cause an error. This can be worked around by including a default section to provide a default value: then if the environment lookup fails, the default value will be used instead. For this to work properly, the
80 B. LibreSSL configuration files default value must be defined earlier in the configuration file than the expansion. See the EXAMPLES section (section B.4 on page 78) for an example of how to do this. If the same variable is defined more than once in the same section, then all but the last value will be silently ignored. In certain circumstances such as with DNs, the same field may occur multiple times. This is usually worked around by ignoring any characters before an initial ‘.’, for example:
1.OU="My first OU" 2.OU="My Second OU"
B.7. BUGS
Currently there is no way to include characters using the octal nnn form. Strings are all NUL n terminated, so NUL bytes cannot form part of the value. The escaping isn’t quite right: if you want to use sequences like ‘ n’, you can’t use any quote n escaping on the same line. Files are loaded in a single pass. This means that a variable expansion will only work if the variables referenced are defined earlier in the file.
B.8. Man Page Notes and Legal
The LATEX source for this man page started as the man page that shipped with LibreSSL 2.9.2 and can be revision identified from the following information:
.\" $OpenBSD: openssl.cnf.5,v 1.5 2019/01/02 07:42:21 jmc Exp $ .\" full merge up to: OpenSSL man5/config b53338cb Feb 28 12:30:28 2017 +0100 .\" selective merge up to: OpenSSL a8c5ed81 Jul 18 13:57:25 2017 -0400
This file was written by Dr. Stephen Henson [[email protected]]. Copyright © 1999, 2000, 2004, 2013, 2015, 2016, 2017 The OpenSSL Project. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of con- ditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software must display the follow- ing acknowledgment: “This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (https://www.openssl.org/)”
81 B. LibreSSL configuration files
4. The names “OpenSSL Toolkit” and “OpenSSL Project” must not be used to endorse or pro- mote products derived from this software without prior written permission. For written per- mission, please contact [email protected].
5. Products derived from this software may not be called “OpenSSL” nor may “OpenSSL” appear in their names without prior written permission of the OpenSSL Project.
6. Redistributions of any form whatsoever must retain the following acknowledgment: “This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (https://www.openssl.org/)”
THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT “AS IS” AND ANY EX- PRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IM- PLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PUR- POSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS CON- TRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEM- PLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PRO- CUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIA- BILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLI- GENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
82 C. X.509 V3 certificate extension configuration format
C.1. DESCRIPTION
Several of the OpenSSL utilities can add extensions to a certificate or certificate request based on the contents of a configuration file. The file format is based on the libressl.cnf(5) (see appendixB on page 75) format. Typically the application will contain an option to point to an extension section. Each line of the extension section takes the form:
extension_name=[critical,] extension_options
If critical is present, then the extension will be critical. The format of extension options depends on the value of extension name. There are four main types of extension: string extensions, multi-valued extensions, raw exten- sions, and arbitrary extensions. String extensions simply have a string which contains either the value itself or how it is obtained. For example:
nsComment="This is a Comment"
Multi-valued extensions have a short form and a long form. The short form is a list of names and values:
basicConstraints=critical,CA:true,pathlen:1
The long form allows the values to be placed in a separate section:
basicConstraints=critical,@bs_section
[bs_section] CA=true pathlen=1
Both forms are equivalent.
83 C. X.509 V3 certificate extension configuration format
The syntax of raw extensions is governed by the extension code: it can for example contain data in multiple sections. The correct syntax to use is defined by the extension code itself: check out the certificate policies extension for an example. If an extension type is unsupported, then the arbitrary extension syntax must be used; see the ARBITRARY EXTENSIONS section (section C.4 on page 91) for more details.
C.2. STANDARD EXTENSIONS
The following sections describe each supported extension in detail.
C.2.1. Basic constraints This is a multi-valued extension which indicates whether a certificate is a CA Certificate. The first (mandatory) name is CA followed by TRUE or FALSE. If CA is TRUE, then an optional pathlen name followed by a non-negative value can be included. For example:
basicConstraints=CA:TRUE basicConstraints=CA:FALSE basicConstraints=critical,CA:TRUE, pathlen:0
A CA Certificate must include the basicConstraints value with the CA field set to TRUE. An end user certificate must either set CA to FALSE or exclude the extension entirely. Some software may require the inclusion of basicConstraints with CA set to FALSE for end entity certificates. The pathlen parameter indicates the maximum number ofCAs that can appear below this one in a chain. So if you have aCA with a pathlen of zero it can only be used to sign end user certificates and not further CA Certificates.
C.2.2. Key usage Key usage is a multi-valued extension consisting of a list of names of the permitted key usages. The supported names are: digitalSignature, nonRepudiation, keyEncipherment, dataEn- cipherment, keyAgreement, keyCertSign, cRLSign, encipherOnly, and decipherOnly. Examples:
keyUsage=digitalSignature, nonRepudiation keyUsage=critical, keyCertSign
C.2.3. Extended key usage This extensions consists of a list of usages indicating purposes for which the certificate public key can be used for.
84 C. X.509 V3 certificate extension configuration format
These can either be object short names or the dotted numerical form of OIDs. While any OID can be used, only certain values make sense. In particular the following PKIX, NS and MS values are meaningful: value meaning serverAuth SSL/TLS web server authentication clientAuth SSL/TLS web client authentication codeSigning code signing emailProtection E-mail protection (S/MIME) timeStamping trusted timestamping OCSPSigning OCSP signing ipsecIKE IPsec internet key exchange msCodeInd Microsoft individual code signing (authenticode) msCodeCom Microsoft commercial code signing (authenticode) msCTLSign Microsoft trust list signing msEFS Microsoft encrypted file system Examples:
extendedKeyUsage=critical,codeSigning,1.2.3.4 extendedKeyUsage=serverAuth,clientAuth
C.2.4. Subject key identifier This is really a string extension and can take two possible values. Either the word hash which will automatically follow the guidelines in RFC 32801 or a hex string giving the extension value to include. The use of the hex string is strongly discouraged. Example:
subjectKeyIdentifier=hash
C.2.5. Authority key identifier The authority key identifier extension permits two options, keyid and issuer: both can take the optional value always. If the keyid option is present, an attempt is made to copy the subject key identifier from the parent certificate. If the value always is present, then an error is returned if the option fails. The issuer option copies the issuer and serial number from the issuer certificate. This will only be done if the keyid option fails or is not included unless the always flag will always include the value. Example:
1https://tools.ietf.org/html/rfc3280
85 C. X.509 V3 certificate extension configuration format
authorityKeyIdentifier=keyid,issuer
C.2.6. Subject alternative name The subject alternative name extension allows various literal values to be included in the configu- ration file. These include email (an email address), URI (a uniform resource indicator), DNS (a DNS domain name), RID (a registered ID: OBJECT IDENTIFIER), IP (an IP address), dirName (a distinguished name), and otherName. The email option can include a special copy value. This will automatically include any email addresses contained in the certificate subject name in the extension. The IP address used in the IP options can be in either IPv4 or IPv6 format. The value of dirName should point to a section containing the distinguished name to use as a set of name value pairs. Multi values AVAs can be formed by prefacing the name with a ‘+’ character. otherName can include arbitrary data associated with an OID: the value should be the OID fol- lowed by a semicolon and the content in standard ASN1 generate nconf(3) format. Examples:
subjectAltName=email:copy,email:[email protected],URI:http://my.url.here/ subjectAltName=IP:192.168.7.1 subjectAltName=IP:13::17 subjectAltName=email:[email protected],RID:1.2.3.4 subjectAltName=otherName:1.2.3.4;UTF8:some other identifier
subjectAltName=dirName:dir_sect
[dir_sect] C=UK O=My Organization OU=My Unit CN=My Name
C.2.7. Issuer alternative name The issuer alternative name option supports all the literal options of subject alternative name. It does not support the email:copy option because that would not make sense. It does support an additional issuer:copy option that will copy all the subject alternative name values from the issuer certificate (if possible). Example:
issuerAltName = issuer:copy
86 C. X.509 V3 certificate extension configuration format
C.2.8. Authority info access The authority information access extension gives details about how to access certain information relating to theCA. Its syntax is accessOID; location where location has the same syntax as subject alternative name (except that email:copy is not supported). accessOID can be any valid OID but only certain values are meaningful, for example OCSP and caIssuers. Example:
authorityInfoAccess = OCSP;URI:http://ocsp.my.host/ authorityInfoAccess = caIssuers;URI:http://my.ca/ca.html
C.2.9. CRL distribution points This is a multi-valued extension whose options can be either in name:value pair form using the same form as subject alternative name or a single value representing a section name containing all the distribution point fields. For a name:value pair a new DistributionPoint with the fullName field set to the given value, both the cRLissuer and reasons fields are omitted in this case. In the single option case, the section indicated contains values for each field. In this section: If the name is fullname, the value field should contain the full name of the distribution point in the same format as subject alternative name. If the name is relativename, then the value field should contain a section name whose con- tents represent a DN fragment to be placed in this field. The name CRLIssuer, if present, should contain a value for this field in subject alternative name format. If the name is reasons, the value field should consist of a comma separated field containing the reasons. Valid reasons are: keyCompromise, CACompromise, affiliationChanged, su- perseded, cessationOfOperation, certificateHold, privilegeWithdrawn, and AA- Compromise. Simple examples:
crlDistributionPoints=URI:http://myhost.com/myca.crl crlDistributionPoints=URI:http://my.com/my.crl,URI:http://oth.com/my.crl
Full distribution point example:
87 C. X.509 V3 certificate extension configuration format
crlDistributionPoints=crldp1_section
[crldp1_section] fullname=URI:http://myhost.com/myca.crl CRLissuer=dirName:issuer_sect reasons=keyCompromise, CACompromise
[issuer_sect] C=UK O=Organisation CN=Some Name
C.2.10. Issuing distribution point This extension should only appear in CRLs. It is a multi-valued extension whose syntax is similar to the ”section” pointed to by the CRL distribution points extension with a few differences. The names reasons and CRLissuer are not recognized. The name onlysomereasons is accepted, which sets this field. The value is in the same format as the CRL distribution point reasons field. The names onlyuser, onlyCA, onlyAA, and indirectCRL are also accepted. The values should be a boolean values (TRUE or FALSE) to indicate the value of the corresponding field. Example:
issuingDistributionPoint=critical, @idp_section
[idp_section] fullname=URI:http://myhost.com/myca.crl indirectCRL=TRUE onlysomereasons=keyCompromise, CACompromise
[issuer_sect] C=UK O=Organisation CN=Some Name
C.2.11. Certificate policies This is a raw extension. All the fields of this extension can be set by using the appropriate syntax. If you follow the PKIX recommendations and just use one OID, then you just include the value of that OID. Multiple OIDs can be set separated by commas, for example:
certificatePolicies= 1.2.4.5, 1.1.3.4
88 C. X.509 V3 certificate extension configuration format
If you wish to include qualifiers, then the policy OID and qualifiers need to be specified in a separate section: this is done by using the @section syntax instead of a literal OID value. The section referred to must include the policy OID using the name policyIdentifier. CP- Suri qualifiers can be included using the syntax:
CPS.nnn=value
userNotice qualifiers can be set using the syntax:
userNotice.nnn=@notice
The value of the userNotice qualifier is specified in the relevant section. This section can include explicitText, organization, and noticeNumbers options. explicitText and organization are text strings, and noticeNumbers is a comma separated list of numbers. The organization and noticeNumbers options (if included) must both be present. If you use the userNotice option with IE5 then you need the ia5org option at the top level to modify the encoding: otherwise it will not be interpreted properly. Example:
certificatePolicies=ia5org,1.2.3.4,1.5.6.7.8,@polsect
[polsect] policyIdentifier = 1.3.5.8 CPS.1="http://my.host.name/" CPS.2="http://my.your.name/" userNotice.1=@notice
[notice] explicitText="Explicit Text Here" organization="Organisation Name" noticeNumbers=1,2,3,4
The ia5org option changes the type of the organization field. In RFC 24592, it can only be of type DisplayText. In RFC 32803, IA5String is also permissible. Some software (for example some versions of MSIE) may require ia5org.
C.2.12. Policy constraints This is a multi-valued extension which consists of the names requireExplicitPolicy or inhibitPolicyMapping and a non-negative integer value. At least one component must be present. Example:
policyConstraints = requireExplicitPolicy:3
2https://tools.ietf.org/html/rfc2459 3https://tools.ietf.org/html/rfc3280
89 C. X.509 V3 certificate extension configuration format
C.2.13. Inhibit any policy This is a string extension whose value must be a non-negative integer. Example:
inhibitAnyPolicy = 2
C.2.14. Name constraints The name constraints extension is a multi-valued extension. The name should begin with the word permitted or excluded, followed by a semicolon. The rest of the name and the value follows the syntax of subjectAltName except email:copy is not supported and the IP form should consist of an IP addresses and subnet mask separated by a slash. Examples:
nameConstraints=permitted;IP:192.168.0.0/255.255.0.0 nameConstraints=permitted;email:.somedomain.com nameConstraints=excluded;email:.com
C.2.15. OCSP no check The OCSP no check extension is a string extension, but its value is ignored. Example:
noCheck = ignored
C.2.16. TLS Feature (aka must staple) This is a multi-valued extension consisting of a list of TLS extension identifiers. Each identifier may be a number in the range from 0 to 65535 or a supported name. When a TLS client sends a listed extension, the TLS server is expected to include that extension in its reply. The supported names are: status request and status request v2. Example:
tlsfeature = status_request
C.3. DEPRECATED EXTENSIONS
The following extensions are non-standard, Netscape specific and largely obsolete. Their use in new applications is discouraged.
90 C. X.509 V3 certificate extension configuration format
C.3.1. Netscape string extensions Netscape comment (nsComment) is a string extension containing a comment which will be dis- played when the certificate is viewed in some browsers. Example:
nsComment = "Some Random Comment"
Other supported extensions in this category are: nsBaseUrl, nsRevocationUrl, nsCaRe- vocationUrl, nsRenewalUrl, nsCaPolicyUrl, and nsSslServerName.
C.3.2. Netscape certificate type This is a multi-valued extensions which consists of a list of flags to be included. It was used to indicate the purposes for which a certificate could be used. The basicConstraints, keyUsage, and extended key usage extensions are now used instead. Acceptable values for nsCertType are: client, server, email, objsign, reserved, sslCA, emailCA, objCA.
C.4. ARBITRARY EXTENSIONS
If an extension is not supported by the OpenSSL code, then it must be encoded using the arbitrary extension format. It is also possible to use the arbitrary format for supported extensions. Extreme care should be taken to ensure that the data is formatted correctly for the given extension type. There are two ways to encode arbitrary extensions. The first way is to use the word ASN1 followed by the extension content using the same syntax as ASN1 generate nconf(3) . For example:
1.2.3.4=critical,ASN1:UTF8String:Some random data 1.2.3.4=ASN1:SEQUENCE:seq_sect
[seq_sect] field1 = UTF8:field1 field2 = UTF8:field2
It is also possible to use the word DER to include the raw encoded data in any extension.
1.2.3.4=critical,DER:01:02:03:04 1.2.3.4=DER:01020304
The value following DER is a hex dump of the DER encoding of the extension. Any extension can be placed in this form to override the default behaviour. For example:
basicConstraints=critical,DER:00:01:02:03
91 C. X.509 V3 certificate extension configuration format
C.5. FILES
/etc/pki/tls/x509v3.cnf standard configuration file
C.6. SEE ALSO
• libressl(1) • ASN1 generate nconf(3) • libressl.cnf(5) (appendixB on page 75)
C.7. HISTORY
X509v3 extension code was first added to OpenSSL 0.9.2.
C.8. CAVEATS
There is no guarantee that a specific implementation will process a given extension. It may there- fore sometimes be possible to use certificates for purposes prohibited by their extensions because a specific application does not recognize or honour the values of the relevant extensions. The DER and ASN1 options should be used with caution. It is possible to create totally invalid extensions if they are not used carefully. If an extension is multi-value and a field value must contain a comma, the long form must be used. Otherwise the comma would be misinterpreted as a field separator. For example,
subjectAltName=URI:ldap://somehost.com/CN=foo,OU=bar
will produce an error, but the following form is valid:
subjectAltName=@subject_alt_section
[subject_alt_section] subjectAltName=URI:ldap://somehost.com/CN=foo,OU=bar
Due to the behaviour of the OpenSSL CONF library, the same field name can only occur once in a section. That means that
subjectAltName=@alt_section
[alt_section] email=steve@here email=steve@there
92 C. X.509 V3 certificate extension configuration format
will only use the last value. This can be worked around by using the form:
[alt_section] email.1=steve@here email.2=steve@there
C.9. Man Page Notes and Legal
The LATEX source for this man page started as the man page that shipped with LibreSSL 2.9.2 and can be revision identified from the following information:
.\" $OpenBSD: x509v3.cnf.5,v 1.5 2018/08/26 18:04:54 jmc Exp $ .\" full merge up to: .\" OpenSSL man5/x509v3_config a41815f0 Mar 17 18:43:53 2017 -0700 .\" selective merge up to: OpenSSL 36cf10cf Oct 4 02:11:08 2017 -0400
This file was written by Dr. Stephen Henson [[email protected]]. Copyright © 2004, 2006, 2013, 2014, 2015, 2016 The OpenSSL Project. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of con- ditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software must display the follow- ing acknowledgment: “This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (https://www.openssl.org/)”
4. The names “OpenSSL Toolkit” and “OpenSSL Project” must not be used to endorse or pro- mote products derived from this software without prior written permission. For written per- mission, please contact [email protected].
5. Products derived from this software may not be called “OpenSSL” nor may “OpenSSL” appear in their names without prior written permission of the OpenSSL Project.
6. Redistributions of any form whatsoever must retain the following acknowledgment: “This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (https://www.openssl.org/)”
93 C. X.509 V3 certificate extension configuration format
THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT “AS IS” AND ANY EX- PRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IM- PLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PUR- POSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS CON- TRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEM- PLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PRO- CUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIA- BILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLI- GENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
94 Part V.
Acronyms and Glossaries
95 96 Acronyms
3DES Tripple DES. 23
AAC Advanced Audio Codec.
AEAD Authenticated Encryption with Associated Data.3, 29, 30, 33, 36
AES Advanced Encryption Standard. 23, 25, 27–30
AES-NI AES New Instruction. 27
CA Certificate Authority. 13, 20–22, 84, 87
CBC Cipher Block Chaining. 29
CRL Certificate Revocation List. 12, 88
CSR Certificate Signing Request. 20–22
DANE DNS Authentication of Named Entities.5, 22
DAV Distributed Authoring and Versioning.
DER Distinguished Encoding Rules. 21, 91
DES Data Encryption Standard.
DH Diffie-Hellman. 27, 33
DHE Diffie-Hellman Ephemeral. 24, 26, 27, 33
DKIM DomainKeys Identified Mail.4
DNS Domain Name System.6, 11
DNSSEC DNS Security Extensions.5
EC Elliptic-Curve. 19
ECDHE Elliptic-Curve Diffie-Hellman Ephemeral. 26, 27
97 Acronyms
ECDSA Elliptic-Curve Digital Signature Algorithm. 18–20, 25–29, 33
EPEL Extra Packages for Enterprise Linux.4,7
FDL GNU Free Document License. ii
FIPS Federal Information Processing Standards.3
FS Forward Secrecy.3, 25, 33, 36
GCM Galois/Counter Mode. 29, 30
GNU GNU’s Not UNIX.3
HAVEGE Hardware Volatile Entropy Gathering and Expansion.7
HSTS HTTP Strict Transport Security. 31, 32
HTTP Hyper-Text Transfer Protocol.3, 31
HTTP/2 HTTP version 2.2,4
HTTPS TLS Secured HTTP. 18, 22
IP Internet Protocol.1, 14
IT Information Technology.
MAC Message Authentication Code. 25–27, 30
MP3 MPEG-1 Layer III.
NIST National Institute of Standards and Technology. 28
NSA National Security Agency.1, 25
OCSP Online Certificate Status Protocol. 12, 13, 21, 85, 90
OID Object Identifier. 76, 77, 79, 80, 85–89
P-256 prime256v1. 19
P-384 secp384r1. 19
PHP People Hate Perl.2,4, 14
PKI Public Key Insfrastructure.
98 Acronyms
PKIX Public Key Infrastructure (X.509). 12, 85, 88 pRNG pseudo-Random Number Generator.3
RACE Research and development in Advanced Communications technologies in Europe.
RIPE RACE Integrity Primitives Evaluation.
RPM RPM Package Manager. 13
RSA Rivest-Shamir-Adleman. 18–20, 25–29, 33
SELinux Security-Enhanced Linux.
SHA-1 Secure Hash Algorithm 1. 25
SHA-2 Secure Hash Algorithm 2.
SMTP Simple Mail Transfer Protocol.3, 12
SSL Secure Socket Layer. 18
TLS Transport Layer Security.1–4, 13, 16, 18, 23–25, 27, 29–33
UDP User Datagram Protocol.1
URI Uniform Resource Indicator.
URL Uniform Resource Locator. 32
VPN Virtual Private Network.
XML eXtensible Markup Language.
99 Main Glossary authentication credentials An identity combined with a single-use token, long-term password or passphrase, or other mechanism by which a user or program authenticates itself to access a protected resource. 14 backdoor An intentional method, usually code inserted into a program, that allows bypassing authentication or encyrption. Some hardware manufacturers will create backdoors in their hardware to make it easier for technicians to remotely access the device without needing authentication. Some government agencies will influence software developers to insert backdoors into soft- ware they write so that the government can access systems that use the software or messages that are encrypted using the software. Some black hats will install backoors on systems they have compromised so that they can access the system again if they are discovered and the method they initially used to gain access is fixed.1–3 black hat A malicious system cracker (often referred to as a hacker though not all hacking is related to system cracking) that attacks systems for nefarious purposes. Contrast with gray hat and white hat.
CA Certificate This can be confusing. This term is frequently used by the general public to indicate an X.509 certificate that has been signed by a Certificate Authority (CA) but that is not how it is used in actual documentation. In actual documentation it refers to a certificate that is allowed to sign other certificates, a certificate that belongs to a Certificate Authority. What we often call a root certificate or an intermediate certificate. 84
Certificate Authority An entity (often a business) that vouches for the public key and associated metadata in an X.509 certificate by signing a CSR with their own private key to create a signed X.509 certificate indicating they trust the public key is associated with the entity named in the CSR (often a domain name but not always). When a message is signed using the private key associated with the public key in the CSR that the Certificate Authority signed, other software and users that trust the Certificate Authority can then trust the authenticity of what was signed.
100 Main Glossary
Certificate Transparency Originally defined in RFC 69624, Certificate Transparency is the practice of aCA making public records of every single certificate they issue. These logs can be scanned by automated tools to detect certificates that were issued but should not have been issued and also can be scanned for certificates issued to domain names that are very similar to domain names likely to be targets of a Phishing attack. Certificate Transparency has improved the security of the World Wide Web. 22 cryptographic hash function A hash function, or algorithm, that has properties making it suit- able for use in cryptography. They are one-way functions meaning you can not determine the data being hashed from the hash itself. They have the so-called ‘butterfly effect’ (sometimes called ‘avalance effect’) where the smallest change in the input being hashed results in an unpredictably different hash value. Given two hash values, it is not possible to know if the source input differed by a single bit or were completely different in every aspect. While mathematically hash collision must exist, it is not possible to find them. If a hash collision is ever found, it indicates a serious flaw in the algorithm and it can no longer be used for cryptography purposes.
Document Root This is the directory on a filesystem that acts as the root for documents to be served by a server daemon (such as Apache or ProFTPD). The server daemon will not serve files that are outside of this directory unless a script called by the daemon reads the file or a configuration directive is used to graft a directory outside the document root into the Document Root (such as the Apache Alias directive). 12–15
GET (HTTP) An HTTP request method where all optional paremeters (if any) for the request are sent as part of the Uniform Resource Indicator (URI) request in the query string. This method is only suitable for retrieving response data.
GNU/Linux Linux is the kernel, developed by Linus Torvalds and initially released in 1991. GNU is the operating system, including the glibc library and the gcc C compiler used to build the Linux kernel and utilities that ‘traditional Linux’ systems use. GNU development started in 1983 and was well-developed by the time Torvalds started working on the Linux kernel. The Linux kernel is released under a GNU license. If you have ever done the Linux From Scratch5 project, it quickly becomes readily apparent just how much GNU software is needed for a minimal bootable system capable of rebuilding itself.
4https://tools.ietf.org/html/rfc6962 5http://www.linuxfromscratch.org/
101 Main Glossary
Some Operating Systems like Android that use the Linux kernel do not use much GNU software if any at all. Referring to ‘traditional Linux’ as ‘GNU/Linux’ distinguishes Linux as many of us have come to know it from those operating systems.1,2 gray hat A system cracker who often breaks laws but does not have a nefarious purpose to their system cracking. They do it to see if they can, for the challenge. Contrast with black hat and white hat. hash collision A hash collision is where two different sets of input data result in the same gen- erated hash value.
HEAD (HTTP) An HTTP request method that asks for a response identical to what would be retrieved with the GET (HTTP) method, but without the response body.
HTTP request method The part of the HTTP request from a client that specifies the desired action to the server. See RFC 72316 section 4.
instance (HTTP) Defined in RFC 32307 as “The entity that would be returned in a [200 OK] re- sponse to a GET (HTTP) request, at the current time, for the selected variant of the specified resource, with the application of zero or more content-codings, but without the application of any instance manipulations or transfer-codings.”
instance manipulation Defined in RFC 32308 as “An operation on one or more [instances (HTTP)] which may result in an instance being conveyed from server to client in parts, or in more than one response message. For example, a range selection or a delta encoding. Instance manipulations are end-to-end, and often involve the use of a cache at the client.”
IPv4 Internet Protocol version Four. A better description is coming. 11, 15
IPv6 Internet Protocol version Six. A bretter description is coming. 11, 14–16
NAT64 A Network Address Translation mechanism that allows IPv6 devices to communicate with hosts that only are available on the IPv4 network. 11
nonce An expression used only once. When used in the context of Information Technology (IT) security it is typically generated with the use of a secure pseudo-Random Number Generator so it can not be predicted. Many are under the impression that nonce stands for ‘Number used Once’ and while that is a good way to think of it, that is not actually the historical etymology, but rather mere coincidence. 28
6https://tools.ietf.org/html/rfc7231 7https://tools.ietf.org/html/rfc3230 8https://tools.ietf.org/html/rfc3230
102 Main Glossary
OpenPGP Defined in RFC 48809, OpenPGP is a social-based mechanism for managing trust in public keys associated with an identity. Unlike X.509, trust is not based upon trust in aCA. The user manages a key ring of keys they trust and decides whether or not to trust a key based upon the reputation of the key, how many keys with a good reputation vouch for the identity associated with the key. This is often referred to as a ‘Web of Trust’. I do not like the system because it has inherent bias in trust level based upon social circles and social skills. This makes it difficult for the socially challenged to obtain a good reputation for their keys but con artists often are very socially adept. There also is a tendency for users to trust an OpenPGP key simply becauase they want the resource that requires their trust. An example, if you want to use LibreLAMP you have to instruct RPM to import my RPM signing key into its keyring of trusted keys. Why do you trust it other than that it is there? RPM would be more secure if it required X.509 validation before allowing a key to be im- ported in my opinion.
Phishing A social engineering attack where the attacker tricks the victim into believing they are interacting with a legitimate web site when in fact they are interacting with a web site controlled by the attacker. Phishing attacks generally involve a domain name that is very similar but slightly different from the domain name used by the legitimate web site the attacker is pretending to be. 22
POST (HTTP) An HTTP request method where data is sent in the body of the request. Usually used with forms and Ajax request. pseudo-Random Number Generator A pRNG is an algorithm that generates new values from a seed value that have the characteristics of a random sequence. When the same seed is used, the same sequence is produced, so technically speaking it is an algorithm produced sequence rather than a random sequence. With a cryptographically secure pRNG it is not possible to increase the odds of correctly guessing a number in the sequence based on any numbers that came before it or after it. A pRNG is usually seeded from the system entropy pool which uses a number of different methods to generate random data that is not from a seeded generator.3
RIPEMD160 160-bit variant of RACE Integrity Primitives Evaluation (RIPE) Message Digest family of cryptographic hash functions. The family was developed in 1992 as a project of the European Union. A collision has been found in the 128-bit variant of the family, but that collision does not effect the 160-bit variant, it is still considered secure.
9https://tools.ietf.org/html/rfc4880
103 Main Glossary
RIPEMD160 is not used very often, but it is used in the Bitcoin project during the process of generating an address from a private key. 35 script kitty A version of Donald Trump Jr. who has had some limited exposure to Python, PHP, or possibly Ruby. SuperCookie A means of uniquely identifying a user to a server that the user is not able to prevent. With normal cookies, a user can delete cookies with some frequency to make tracking of their online activity more difficult for nefarious privacy invasive companies more difficult. The term SuperCookie was invented to refer to tracking methods that perform the same function as a tracking cookie but are not so easily deleted.
TLS session resumption First defined in RFC 450710, TLS, session resumption allows a client that has recently connected to a TLS server to reconnect to the server by resuming the previ- ous session thus avoiding the costly handshake negotiation required for a new session. This brings real performance benefits but it should be used with caution, TLS session re- sumption can result in privacy issues such as third party tracking even when a Virtual Private Network (VPN) is used and all browser cookies are cleared. With uses cases such as a mail server connecting to another mail server, these privacy con- cerns are not an issue. They are however an issue for web browsers where they can be abused to track users as a form of SuperCookie.
See https://www.privateinternetaccess.com/blog/2018/11/supercookey-a-supercookie-built-into-tls-1-2-and-1-3/ Two Factor Authentication A security mechanism to reduce the impact of stolen authentica- tion credentials. In addition to the primary mechanism of authentication, a second mecha- nism is used to reduce the possibility that a nefarious entity with stolen authentication cre- dentials can access a protected resource. The second form of authentication usually but not always involves a nonce that is generated after the first authentication mechanism is successful. The nonce is sent via a mechanism (such as text message on a phone) that only the legitimate user is likely to have access to.
WebDAV An implementation of Distributed Authoring and Versioning (DAV) over HTTP. See RFC 491811. webmaster The person who is primarily responsible for content and user-space web application maintenance for a web site. The webmaster often is also the content creator and system administrator but that is not always the case. 11, 12, 14
10https://tools.ietf.org/html/rfc4507 11https://tools.ietf.org/html/rfc4918
104 Main Glossary white hat A security researcher / penetration tester who does not (intentionally) violate any laws while looking for security vulnerabilities and how to prevent them. Contrast with gray hat and black hat.
X.509 A cryptography standard for the management of public keys, validation of public keys, and limitations of what those public keys can be used for. X.509 is different than OpenPGP which uses social reputation to manage trust in public keys and does not facilitate limitations of what contexts a key should be limited for. Rather, X.509 uses a hierarchal ‘Chain of Trust’ often referred to as PKIX. Each X.509 certificate (often incorrectly referred to as a TLS or SSL certificate) contains a public key from a cryptography key pair along with metadata parameters that specify who the associated private key belongs to, what contexts it is to be considered valid for, when the key expires, and usually a link to a CRL or OCSP resource that can be used to verify that trust has not been revoked. The public key and associated metadata is then signed by the private key of an entity that vouches for the information in the X.509 certificate. When the PKIX system trusts the signer of X.509 certificate (referred to as aCA) and verifies the signature has not been revoked by thatCA, the X.509 certificate can be trusted and the public key can be used to validate data signed by the associated private key.1, 12, 25, 26, 33
YUM The package manager used by CentOS 7 to install and update RPM packages.8,9, 11
105 HTTP Status Codes
1XX Informational response HTTP response codes that indicate the request has been received and understood by the server.
100 Continue The request headers have been received, the client should send the request body. When clients wish to send a large content body, the should initially just send the request headers including a Expect: 100-continue header. If the server is willing to accept the request, it will respond with this header and the client may continue to send the request body.
101 Switching Protocols The client has sent a request to switch protocols and the server is capable and willing to do so.
102 Processing WebDAV requests may require file system operations that take some time to complete. This header lets the client the request has been received and is being processed but is not yet complete. Sending this header prevents the client from assuming the connection has timed out and wasting resources by attempting the request again. See RFC 251812.
103 Early Hints This is used to send some response headers before the final HTTP message is sent. See RFC 829713.
2XX Success response HTTP response codes that indicate the request has been received and understood and successfully acted upon.
200 OK The request is successfully handled by the server. This is the response most commonly sent when the request is good and everything is working as it should.
201 Created The request to create a new resource has been completed.
202 Accepted The server has accepted the request but it has not yet processed the request.
12https://tools.ietf.org/html/rfc2518 13https://tools.ietf.org/html/rfc8297
106 HTTP Status Codes
203 Non-Authoritative Information The server is a proxy that modifies content. It received a 200 OK from the origin and is returning a modified version of that response. This is mostly used for accelerator proxies, e.g. services that compress images and other resources reducing the bandwidth needed by the requesting client. 204 No Content The request was successfully processed but the server is not returning any con- tent. 205 Reset Content The request was successfully processed but no content is being sent. The client needs to reset the document view. 206 Partial Content The request was successfully processed but the response only includes part of the content. This is used when the client specifies a byte range and is usually used when resuming a download or with multimedia files that are large. See RFC 723314. 207 Multi-Status Used with WebDAV. The message body is usually eXtensible Markup Lan- guage (XML) and can contain separate response codes. See RFC 491815. 208 Already Reported Used with WebDAV. Members of a DAV binding have already been enumerated and are not being included again. See RFC 584216. 226 IM Used The request was successful and the response represents one or more instance ma- nipulations to be applied to the current instance (HTTP). See RFC 322917. 3XX Redirect response HTTP response codes that directs the client to take additional action to complete the request. 300 Multiple Choices A redirect but with multiple choices for the client to choose from. This is sometimes done to allow the client to select a preferred multimedia format, such as Advanced Audio Codec (AAC) or MPEG-1 Layer III (MP3). 301 Moved Permanently A redirect telling the client the resource has been moved permanently. The client may cache the URL so it can apply the redirect in the future without making the request, and the client may update bookmarks that point to the old URL so that they now point to the redirect URL. 15
14https://tools.ietf.org/html/rfc7233 15https://tools.ietf.org/html/rfc4918 16https://tools.ietf.org/html/rfc5842 17https://tools.ietf.org/html/rfc3229
107 HTTP Status Codes
302 Found The behavior of browsers with this response code is not consistent. It should be avoided. Originally it was intended to have the behavior of 307 Temporary Redirect but browsers did not implement it correctly. 303 See Other was added to give the type of functionallity browsers implemented, and 307 Temporary Redirect was added to give the original function of 302 but with a new code. Most browsers treat a 302 response code as if it were 303.
303 See Other The response the client seeks can be found at the specified URL.
304 Not Modified Used to tell a client that the response has not changed since the version the client specified in its request header, it should use that response. This is used when a client has cached a response but the client is not sure if the cached version it has is current. The client will send a new request for the resource including information about the version of the file it has. If the version it has is current, the server sends this header and the client does not need to receive new data. If the version is not current, then the server will either send the updated response data or a different header such as 404 Not Found if the resource does not exist. See RFC 723218.
305 Use Proxy A redirect to a proxy to retrieve the resource from. Due to security concerns, many browsers do not implement the behavior this status code is intended for.
306 Switch Proxy Deprecated. The response is fulfilled, but future requests for the resource should go through the specified proxy. This status code is no longer implemented by clients.
307 Temporary Redirect The resource is temporarily located at a different location. Use that location to retrieve it, but do not cache the redirect or update bookmarks.
308 Permanent Redirect Very similar to 301 Moved Permanently except the method can not change. So if a 308 response is sent for a POST (HTTP) form request, the client will use POST with the redirect URL. See RFC 753819.
4XX Client error response HTTP response codes that indicate the server can not complete the request due to a bad client request.
400 Bad Request The request was not processed because it contains an error.
18https://tools.ietf.org/html/rfc7232 19https://tools.ietf.org/html/rfc7538
108 HTTP Status Codes
401 Unauthorized The request can not be processed due to failed or lacking authentication cre- dentialss. This differs from a 403 Forbidden header in that it is specifically for requests where authen- tication credentialss are sent performed using Basic Access Authentication or Digest Access Authentication. See RFC 723520.
402 Payment Required Client behavior for this response code is not yell defined and I doubt it ever will be, the HTTP protocol is the wrong place for handling billing issues. I believe the original intent was for a digital cash system allowing payments to be made through the browser software itself to access a resource but securing such a system is just not feasible. Some websites do use the response code, but most just redirect to a web page where the customer can pay for access to the resource.
403 Forbidden The request was successfully received but the server is refusing to respond. This response is usually sent when the resquest is for a protected resource but the client did not send validating authentication credentials. 17
404 Not Found The requested resource was not found by the server. It may be available in the future.
405 Method Not Allowed The requested HTTP request method is not allowed for the requested resource. An example would be trying to use POST (HTTP) on a resource that only allows GET (HTTP).
406 Not Acceptable The resource requested can not be served in compliance with the specified Accept headers sent with the request.
407 Proxy Authentication Required The proxy requires authentication credentials the client has not supplied. See RFC 723521.
408 Request Timeout The client took too long to finish making the request.
409 Conflict The request can not be completed due to a conflict in the state of the resource. An example of where this could happen is two attempt to modify the same resource taking place.
20https://tools.ietf.org/html/rfc7235 21https://tools.ietf.org/html/rfc7235
109 HTTP Status Codes
410 Gone The requested resource use to exist but it has been removed and will not be replaced. This differs from a 404 Not Found in that clients (and search engines) should not attempt to request the same resource again but should treat the resource as permanently purged. Legitimate use cases for this response code are rare, but one such use case would be a re- source that has been removed for legal reasons, such as content found to be in violation of obsenity laws or content found to violate intellectual property laws.
411 Length Required The requested resource requires the client specify the length of its con- tent.
412 Precondition Failed A request specified precondition can not be met by the server. See RFC 723222.
413 Payload Too Large The request is larger than the server allows. See RFC 723123.
414 URI Too Long The URI is larger than what the server allows. Usually this results from a GET (HTTP) request with too much data encoded within the query string. See RFC 723124.
415 Unsupported Media Type The request includes a media type that is not supported by the server.
416 Range Not Satisfiable The byte range the client requested can not be supplied by the server. Usually this is because the client is asking for bytes beyond the end of the file. See RFC 723325.
417 Expectation Failed The conditions in the Expect header were not able to be met.
418 I’m a teapot When the client requests the server brew coffee but the server is a tea pot, this status is returned. See RFC 232426 and RFC 716827.
22https://tools.ietf.org/html/rfc7232 23https://tools.ietf.org/html/rfc7231 24https://tools.ietf.org/html/rfc7231 25https://tools.ietf.org/html/rfc7233 26https://tools.ietf.org/html/rfc2324 27https://tools.ietf.org/html/rfc7168
110 HTTP Status Codes
421 Misdirected Request The request was directed at a server that is not able to produce a response. See RFC 754028.
422 Unprocessable Entity Used with WebDAV. The request was well-formed but could not be processed due to semantic errors. See RFC 491829.
423 Locked Used with WebDAV. The resource being accessed is locked. See RFC 491830.
424 Failed Dependency Used with WebDAV. The request failed because it depended on an- other request that failed. See RFC 491831.
425 Too Early Used with TLS 1.3 0-RTT TLS session resumption. The server will not process the request because it might be used in a replay attack. See RFC 847032.
426 Upgrade Required To access the resource, the client must upgrade to a different protocol.
428 Precondition Required The server requires the request to be conditional. See RFC 658533.
429 Too Many Requests The client has made too many requests in a given amount of time. See RFC 658534.
5XX Client error response HTTP response codes that indicate the request can not be com- pleted due to a server error.
Non-standard response Some companies and products make up their own HTTP response codes. Some of them are humorous but it really is a bad idea to do this.
28https://tools.ietf.org/html/rfc7540 29https://tools.ietf.org/html/rfc4918 30https://tools.ietf.org/html/rfc4918 31https://tools.ietf.org/html/rfc4918 32https://tools.ietf.org/html/rfc8470 33https://tools.ietf.org/html/rfc6585 34https://tools.ietf.org/html/rfc6585
111 Extensive amounts of blood, sweat, tears, and time went into the authoring of this manual.
The author as of 2019 is living well below the poverty line.
Please consider a financial contribution at
https://www.paypal.me/pipfrosch
Thank you.
112