SMOLNET PORTAL home about changes
[root][parent][raw file]
openssl - sfeed_tests - sfeed tests and RSS and Atom files
(URL) git clone git://git.codemadness.org/sfeed_tests (git://git.codemadness.org)
(DIR) Log
(DIR) Files
(DIR) Refs
(DIR) README
(DIR) LICENSE
---
openssl (90873B)
---
1 <?xml version="1.0" encoding="utf-8"?>
2 <feed xmlns="http://www.w3.org/2005/Atom">
3
4 <title><![CDATA[OpenSSL Blog]]></title>
5 <link href="https://www.openssl.org/blog/atom.xml" rel="self"/>
6 <link href="https://www.openssl.org/blog/"/>
7 <updated>2020-09-05T09:04:25+00:00</updated>
8 <id>https://www.openssl.org/blog/</id>
9 <author>
10 <name><![CDATA[OpenSSL Foundation, Inc.]]></name>
11
12 </author>
13 <generator uri="http://octopress.org/">Octopress</generator>
14
15
16 <entry>
17 <title type="html"><![CDATA[OpenSSL Is Looking for a Full Time Administrator and Manager]]></title>
18 <link href="https://www.openssl.org/blog/blog/2020/09/05/OpenSSL.ProjectAdminRole/"/>
19 <updated>2020-09-05T10:00:00+00:00</updated>
20 <id>https://www.openssl.org/blog/blog/2020/09/05/OpenSSL.ProjectAdminRole</id>
21 <content type="html"><![CDATA[<p>The OpenSSL Management Committee are looking to hire a full time Administrator
22 and Manager. Details of the role follow.</p>
23
24 <p>To apply please send your cover letter and resume to <a href="&#109;&#97;&#x69;&#x6c;&#x74;&#x6f;&#x3a;&#x6a;&#111;&#x62;&#115;&#64;&#x6f;&#x70;&#101;&#110;&#115;&#115;&#x6c;&#46;&#111;&#114;&#x67;">&#x6a;&#111;&#x62;&#115;&#64;&#111;&#x70;&#x65;&#110;&#x73;&#115;&#x6c;&#46;&#x6f;&#114;&#x67;</a> by 20th
25 September 2020.</p>
26
27 <!-- more -->
28
29
30 <h1>Job Title</h1>
31
32 <p>OpenSSL Administrator and Manager</p>
33
34 <h1>Reports To</h1>
35
36 <p>The OpenSSL Administrator and Manager will report to the OpenSSL Management
37 Committee (OMC).</p>
38
39 <h1>About OpenSSL</h1>
40
41 <p>The OpenSSL Project develops and maintains the OpenSSL software - a robust,
42 commercial-grade, and full-featured toolkit for the Transport Layer Security
43 (TLS) and Secure Sockets Layer (SSL) protocols. It is also a general-purpose
44 cryptography library. The software is widely used around the globe by thousands
45 of organisations, including many major household name corporations. The OpenSSL
46 software is released under an open source licence and is available for free to
47 anyone that wants to use it.</p>
48
49 <p>The software is developed by a distributed team, mostly consisting of
50 volunteers with some paid developers. Development is managed by the OMC.</p>
51
52 <h1>Job Overview</h1>
53
54 <p>This full time role will assist the OMC in administering and managing the
55 OpenSSL Project and its associated companies - the OpenSSL Software Foundation
56 (OSF), and OpenSSL Software Services (OSS). This will cover a broad range of
57 responsibilities and duties. You must be be a self motivated and self directed
58 individual comfortable with working by yourself for protracted periods of time
59 whilst fitting into a small globally distributed team mostly consisting of
60 volunteers.</p>
61
62 <p>You will be primarily based from home with occasional business trips and
63 you may reside anywhere in the world. Since the project has members from
64 around the world, virtual meetings are often held outside of normal business
65 hours to accommodate different timezones and so you will be expected to be
66 flexible about when you will be available.</p>
67
68 <h1>Responsibilities and Duties</h1>
69
70 <ul>
71 <li>Assisting the part time directors in their duties</li>
72 <li>Assisting with the secretarial &amp; treasurer duties (such as following up on
73 payments, answering supplier questionnaires etc)</li>
74 <li>Be a business contact point for support customers and take responsibility for
75 the support contract renewal process, new support contract negotiations and
76 customer on-boarding (including creation of user accounts and repositories)</li>
77 <li>Take responsibility for status tracking/admin during technical meetings (for
78 example regular meetings with our FIPS sponsors, and developer team meetings)</li>
79 <li>Project Management, tracking and reporting of large pieces of work</li>
80 <li>Ongoing tracking and reporting on github issues and pull requests</li>
81 <li>Outbound communications such as writing newsletters, blogs, press releases</li>
82 <li>Tracking and management of incoming security reports - ensuring that all
83 incoming reports are responded to in a timely manner, and appropriate
84 technical resources are assigned to: triage and analyse the reports, produce
85 fixes, write security advisories, etc</li>
86 <li>Manage the security pre-notification process where necessary</li>
87 <li>Organise face-2-face and/or virtual meetings</li>
88 <li>Review and register incoming Contributor Licence Agreements (CLAs)</li>
89 <li>Wiki user account creation</li>
90 <li>When required, writing job descriptions and handling the hiring and
91 negotiation process</li>
92 <li>Other similar duties as they may arise, and as directed by the OMC</li>
93 </ul>
94
95
96 <h1>Qualifications and Experience</h1>
97
98 <p>You must have excellent spoken and written English. While not a technical role
99 you will be interacting with highly technical people on a daily basis so a broad
100 background and understanding of software development is essential. You may need
101 to interact with command line tools to perform or aid your duties. An
102 understanding of Cryptography and/or TLS concepts is an advantage but not
103 required. You will have a proven track record in a Project or Technical
104 Management role in a software development environment. An interest or background
105 in Open Source development is also an advantage.</p>
106
107 <p>You must be able to travel to meeting locations around the globe on an
108 occasional basis including Europe, North America, and Australia.</p>
109
110 <h1>Salary</h1>
111
112 <p>Commensurate with experience and location.</p>
113 ]]></content>
114 </entry>
115
116 <entry>
117 <title type="html"><![CDATA[OpenSSL 3.0 Alpha4 Release]]></title>
118 <link href="https://www.openssl.org/blog/blog/2020/06/25/OpenSSL3.0Alpha4/"/>
119 <updated>2020-06-25T19:00:00+00:00</updated>
120 <id>https://www.openssl.org/blog/blog/2020/06/25/OpenSSL3.0Alpha4</id>
121 <content type="html"><![CDATA[<p>The OpenSSL Management Committee and the OpenSSL Technical Committee are glad to
122 announce the fourth alpha release of OpenSSL 3.0.</p>
123
124 <!-- more -->
125
126
127 <p>As any alpha release, the code is still experimental and many things can still
128 change before the feature freeze planned for the beta release. In the following
129 weeks more alpha releases will be issued to add more functionality, polish and
130 improve the code and fix issues.</p>
131
132 <p>We have been talking about the development of the next major release of OpenSSL
133 for a while, and you can read more about it in previous blog posts and read more
134 about the planned changes in our <a href="https://www.openssl.org/docs/OpenSSL300Design.html">design document</a>.</p>
135
136 <p>This release comes after three more weeks since the last alpha pre-release, and
137 saw a number of changes: 193 commits from 76 PRs, 535 files changed, with 107313
138 insertions and 11467 deletions.</p>
139
140 <p>Among these changes, we can mention, in no particular order:</p>
141
142 <ul>
143 <li>general improvements to the built-in providers, the providers API and the
144 internal plumbing and the provider-aware mechanisms for <code>libssl</code>;</li>
145 <li>general improvements and fixes in the CLI apps;</li>
146 <li>support for Automated Cryptographic Validation Protocol (ACVP) tests;</li>
147 <li>fully pluggable TLS key exchange capability from providers;</li>
148 <li>finalization of the Certificate Management Protocol (CMP) contribution, adding
149 an impressive amount of tests for the new features;</li>
150 <li>default to the newer SP800-56B compliant algorithm for RSA keygen;</li>
151 <li>provider-rand: PRNG functionality backed by providers;</li>
152 <li>refactored naming scheme for dispatched functions (<a href="https://github.com/openssl/openssl/pull/12222">#12222</a>);</li>
153 <li>fixes for various issues;</li>
154 <li>extended and improved test coverage;</li>
155 <li>additions and improvements to the documentations.</li>
156 </ul>
157
158
159 <p>This latest development cycle has seen an increasing amount of efforts in
160 polishing and fixes, thanks to the feedback and help from the community that is
161 assisting during the alpha development stage and the addition of higher level
162 functionality that is tying in together different components of the new provider
163 infrastructure.
164 We wish once more to reiterate our thanks for all the feedback and the
165 contributions from the users and developers that are testing the pre-release
166 versions of OpenSSL, which are vital to the development process of the next
167 release.</p>
168
169 <p>For more details on upgrading to OpenSSL 3.0 from previous versions, as well as
170 known issues and the status of current development, we collected specific notes
171 on the <a href="https://wiki.openssl.org/index.php/OpenSSL_3.0">OpenSSL wiki</a>. We strongly encourage consulting (and
172 contributing to) this wiki entry also to discover the most important changes in
173 the upcoming OpenSSL 3.0 and how they might affect you and the code you
174 maintain.</p>
175
176 <p>We are always keen to see oldtimers and newcomers alike proposing issues, fixes
177 and contributions, not only in the form of code, but also for manpages and wiki
178 documentation. At this point, it is particularly important to also make sure
179 that the documentation for the new architecture, for the new features, and for
180 the new deprecations and their replacements, is available, complete, up-to-date
181 and sufficiently clear for external users.
182 We prioritize GitHub issues and pull requests as the favourite channel for
183 contributing to the <a href="https://github.com/openssl/openssl/projects/2">OpenSSL 3.0 project</a>, but any form of
184 interaction, including on the <a href="https://www.openssl.org/community/mailinglists.html"><code>openssl-users</code> mailing list</a>, is
185 always welcome.</p>
186
187 <p>The feedback from the community, and your involvement in testing external
188 applications and <em>ENGINEs</em> against the next version of OpenSSL and improving the
189 documentation is crucial to the continued quality of the OpenSSL Project.</p>
190 ]]></content>
191 </entry>
192
193 <entry>
194 <title type="html"><![CDATA[OpenSSL 3.0 Alpha3 Release]]></title>
195 <link href="https://www.openssl.org/blog/blog/2020/06/05/OpenSSL3.0Alpha3/"/>
196 <updated>2020-06-05T12:00:00+00:00</updated>
197 <id>https://www.openssl.org/blog/blog/2020/06/05/OpenSSL3.0Alpha3</id>
198 <content type="html"><![CDATA[<p>The OpenSSL Management Committee and the OpenSSL Technical Committee are glad to
199 announce the third alpha release of OpenSSL 3.0.</p>
200
201 <!-- more -->
202
203
204 <p>As any alpha release, the code is still experimental and many things can still
205 change before the feature freeze planned for the beta release. In the following
206 weeks more alpha releases will be issued to add more functionality, polish and
207 improve the code and fix issues.</p>
208
209 <p>We have been talking about the development of the next major release of OpenSSL
210 for a while, and you can read more about it in previous blog posts and read more
211 about the planned changes in our <a href="https://www.openssl.org/docs/OpenSSL300Design.html">design document</a>.</p>
212
213 <p>This release comes after three more weeks since the last alpha pre-release, and
214 saw a number of changes: 352 files were changed, with 7117 insertions and 3567
215 deletions.
216 Among these changes, we can mention, in no particular order:</p>
217
218 <ul>
219 <li>general improvements to the built-in providers, the providers API and the
220 internal plumbing and the provider-aware mechanisms for <code>libssl</code>;</li>
221 <li>general improvements and fixes in the CLI apps;</li>
222 <li>cleanup of the EC API:
223
224 <ul>
225 <li><code>EC_METHOD</code> became an internal-only concept, and functions using or
226 returning <code>EC_METHOD</code> arguments have been deprecated;</li>
227 <li><code>EC_POINT_make_affine()</code> and <code>EC_POINTs_make_affine()</code> have been deprecated
228 in favor of automatic internal handling of conversions when needed;</li>
229 <li><code>EC_GROUP_precompute_mult()</code>, <code>EC_GROUP_have_precompute_mult()</code>, and
230 <code>EC_KEY_precompute_mult()</code> have been deprecated, as such precomputation data
231 is now rarely used;</li>
232 <li><code>EC_POINTs_mul()</code> has been deprecated, as for cryptographic applications
233 <code>EC_POINT_mul()</code> is enough.</li>
234 </ul>
235 </li>
236 <li>the <code>CMS</code> API got support for CAdES-BES signature verification;</li>
237 <li>introduction of a new <code>SSL_OP_IGNORE_UNEXPECTED_EOF</code> option;</li>
238 <li>improvements to the RSA OAEP support;</li>
239 <li>FFDH support in the <code>speed</code> app;</li>
240 <li>CI: added external testing through the GOST engine;</li>
241 <li>fixes for various issues;</li>
242 <li>extended and improved test coverage;</li>
243 <li>additions and improvements to the documentations.</li>
244 </ul>
245
246
247 <p>Once more, a lot of these enhancements wouldn&rsquo;t have happened without the
248 positive response of the community to previous alpha announcements.
249 We wish to reiterate our thanks for all the feedback and the contributions from
250 the users and developers that are testing the pre-release versions of OpenSSL,
251 which are vital to the development process of the next release.</p>
252
253 <p>As a special note, I&rsquo;d like to highlight in this occasion that recently the
254 OpenSSL Management Committee published a message on the <a href="https://www.openssl.org/community/mailinglists.html"><code>openssl-project</code> mailing list</a>
255 seeking assistance from the community to take on a task related to the inclusion
256 of X9.42 KDF into the upcoming FIPS provider in time for the FIPS validation
257 process for OpenSSL 3.0. More details can be found in the
258 <a href="https://www.mail-archive.com/openssl-project@openssl.org/msg01850.html">original message</a>.</p>
259
260 <p>For more details on upgrading to OpenSSL 3.0 from previous versions, as well as
261 known issues and the status of current development, we collected specific notes
262 on the <a href="https://wiki.openssl.org/index.php/OpenSSL_3.0">OpenSSL wiki</a>. We strongly encourage consulting (and
263 contributing to) this wiki entry also to discover the most important changes in
264 the upcoming OpenSSL 3.0 and how they might affect you and the code you
265 maintain.</p>
266
267 <p>We are always keen to see oldtimers and newcomers alike proposing issues, fixes
268 and contributions, not only in the form of code, but also for manpages and wiki
269 documentation. At this point, it is particularly important to also make sure
270 that the documentation for the new architecture, for the new features, and for
271 the new deprecations and their replacements, is available, complete, up-to-date
272 and sufficiently clear for external users.
273 We prioritize GitHub issues and pull requests as the favourite channel for
274 contributing to the <a href="https://github.com/openssl/openssl/projects/2">OpenSSL 3.0 project</a>, but any form of
275 interaction, including on the <a href="https://www.openssl.org/community/mailinglists.html"><code>openssl-users</code> mailing list</a>, is
276 always welcome.</p>
277
278 <p>The feedback from the community, and your involvement in testing external
279 applications and <em>ENGINEs</em> against the next version of OpenSSL and improving the
280 documentation is crucial to the continued quality of the OpenSSL Project.</p>
281 ]]></content>
282 </entry>
283
284 <entry>
285 <title type="html"><![CDATA[OpenSSL 3.0 Alpha2 Release]]></title>
286 <link href="https://www.openssl.org/blog/blog/2020/05/16/OpenSSL3.0Alpha2/"/>
287 <updated>2020-05-16T12:00:00+00:00</updated>
288 <id>https://www.openssl.org/blog/blog/2020/05/16/OpenSSL3.0Alpha2</id>
289 <content type="html"><![CDATA[<p>The OpenSSL Management Committee and the OpenSSL Technical Committee are glad to
290 announce the second alpha release of OpenSSL 3.0.</p>
291
292 <!-- more -->
293
294
295 <p>As any alpha release, the code is still experimental and many things can still
296 change before the feature freeze planned for the beta release. In the following
297 weeks more alpha releases will be issued to add more functionality, polish and
298 improve the code and fix issues.</p>
299
300 <p>We have been talking about the development of the next major release of OpenSSL
301 for a while, and you can read more about it in previous blog posts and read more
302 about the planned changes in our <a href="https://www.openssl.org/docs/OpenSSL300Design.html">design document</a>.</p>
303
304 <p>For the lovers of statistics, in the 3 weeks since the first alpha pre-release,
305 582 files were changed, with 12867 insertions and 4717 deletions!
306 Among these changes, we can mention:</p>
307
308 <ul>
309 <li>general improvements to the built-in providers, the providers API and the
310 internal plumbing;</li>
311 <li>the removal of legacy API functions related to FIPS mode, replaced by new
312 provider-based mechanisms;</li>
313 <li>the addition of a new <code>cmp</code> app for RFC 4210;</li>
314 <li>extended and improved test coverage;</li>
315 <li>improvements to the documentations;</li>
316 <li>fixes for various issues.</li>
317 </ul>
318
319
320 <p>In announcing this new pre-release, we particularly wish to thank the community
321 for the great response to the previous alpha.
322 Many of the issues fixed and the other improvements have been possible thanks to
323 the feedback and the contributions sent by all the users and developers that
324 heeded the previous announcements or regularly follow development on the git
325 <code>master</code> branch, and helped with the testing.</p>
326
327 <p>On a personal author note, the level and quality of engagement from the whole
328 community since the previous pre-release has been astonishing, and I&rsquo;d like to
329 take advantage of this blog post also to personally and explicitly thank all the
330 new first-time contributors that started collaborating with the OpenSSL Project
331 in the past weeks!</p>
332
333 <p>Resuming with the announcement and the useful information: once more, we invite
334 the OpenSSL community to download and test this alpha release to provide early
335 feedback, prioritizing GitHub issues and pull requests as the favourite channel
336 for contributing to the <a href="https://github.com/openssl/openssl/projects/2">OpenSSL 3.0 project</a>.</p>
337
338 <p>For more details on upgrading to OpenSSL 3.0 from previous versions, as well as
339 known issues and the status of current development, we collected specific notes
340 on the <a href="https://wiki.openssl.org/index.php/OpenSSL_3.0">OpenSSL wiki</a>. We strongly encourage consulting (and
341 contributing to) this wiki entry also to discover the most important changes in
342 the upcoming OpenSSL 3.0 and how they might affect you and the code you
343 maintain.</p>
344
345 <p>We are always keen to see oldtimers and newcomers alike proposing issues, fixes
346 and contributions, not only in the form of code, but also for manpages and wiki
347 documentation. At this point, it is particularly important to also make sure
348 that the documentation for the new architecture, for the new features, and for
349 the new deprecations and their replacements, is available, complete, up-to-date
350 and sufficiently clear for external users.</p>
351
352 <p>The feedback from the community, and your involvement in testing external
353 applications and <em>ENGINEs</em> against the next version of OpenSSL and improving the
354 documentation is crucial to the continued quality of the OpenSSL Project.</p>
355 ]]></content>
356 </entry>
357
358 <entry>
359 <title type="html"><![CDATA[Security Policy Update on Prenotifications]]></title>
360 <link href="https://www.openssl.org/blog/blog/2020/05/12/security-prenotifications/"/>
361 <updated>2020-05-12T09:00:00+00:00</updated>
362 <id>https://www.openssl.org/blog/blog/2020/05/12/security-prenotifications</id>
363 <content type="html"><![CDATA[<p>We&rsquo;re planning to extend who we prenotify of any future High and Critical
364 security issues.</p>
365
366 <!-- more -->
367
368
369 <p>Last month we dealt with a High severity security vulnerability which affected
370 some versions of OpenSSL,
371 <a href="https://www.openssl.org/news/secadv/20200421.txt">CVE-2020-1967</a></p>
372
373 <p>While we fix Low and Moderate issues from time to time, fortunately High and Critical
374 issues are quite rare. The previous High severity vulnerability was over 3
375 years earlier in 2017
376 <a href="https://www.openssl.org/news/secadv/20170216.txt">CVE-2017-3733</a> and the last
377 Critical was in 2016
378 <a href="https://www.openssl.org/news/secadv/20160926.txt">CVE-2016-6309</a></p>
379
380 <p>Our <a href="https://www.openssl.org/policies/secpolicy.html">Security Policy</a> outlines
381 some of the principles on how we deal with issues; it&rsquo;s our aim to keep issues
382 private for as little time as possible, but also to give notice of High and
383 Critical issues in advance to distributions in such a way as we can get more
384 users protected from the start.</p>
385
386 <p>It&rsquo;s always been a trade-off; so many things ship OpenSSL in them, even more
387 have OpenSSL as a dependency, and so many of these consumer companies would
388 like to know about issues in advance. However the more people we tell the
389 higher the chances of a leak, but also the longer it takes to do the
390 prenotification. We want to keep the time an issue is private as short as we
391 can, and our prenotification period is 7 days or less. Additionally, these
392 prenotifications use up a lot of our time as they require lots of 1:1
393 interactions and are always more involved than sending a single email blast
394 with an advisory and patch. Often at the start of the process we don&rsquo;t have a
395 complete understanding of the issue so the advisory and patch change, sometimes
396 several times, and sometimes these get altered right up to the last minute of
397 release, as we gain feedback from distros based on their testing and review.</p>
398
399 <p>The OMC voted this week to <a href="https://github.com/openssl/web/pull/176/files">update our security policy</a>
400 to include the option of
401 us giving prenotification to companies with which we have a commercial
402 relationship. (Edited to clarify: the vote was to allow notification to our Premium
403 Support customers and this does not include lower support levels, sponsors, or GitHub
404 sponsors.) We believe this gives a balance of how to pick a few companies
405 that can help test and feedback on the fix; where we&rsquo;ve already committed time
406 from our paid resources to work with those companies, and also while not
407 overloading us with extra work or overly increasing the risk of early leaks.</p>
408
409 <p>This change does not have any other effect on our principles, nor does it
410 change who we already notify about issues outside of those commercial
411 relationships. All these prenotifications will be under the same terms and
412 timescales, and we will always choose to do the right thing for our community
413 as a whole and not be influenced by commercial agreements. So we&rsquo;re still
414 going to get updates for High and Critical issues out as quickly as we can and
415 keep embargoes to the minimum possible, generally 7 days or less.</p>
416
417 <p>Thankfully severe OpenSSL security issues are quite rare. We recommend users
418 of OpenSSL subscribe to our <a href="https://mta.openssl.org/mailman/listinfo/openssl-announce">openssl-announce mailing list</a> to get our
419 announcements and advisories.</p>
420 ]]></content>
421 </entry>
422
423 <entry>
424 <title type="html"><![CDATA[OpenSSL 3.0 Alpha1 Release]]></title>
425 <link href="https://www.openssl.org/blog/blog/2020/04/23/OpenSSL3.0Alpha1/"/>
426 <updated>2020-04-23T12:00:00+00:00</updated>
427 <id>https://www.openssl.org/blog/blog/2020/04/23/OpenSSL3.0Alpha1</id>
428 <content type="html"><![CDATA[<p>The OpenSSL Management Committee and the OpenSSL Technical Committee are glad to
429 announce the first alpha release of OpenSSL 3.0.</p>
430
431 <!-- more -->
432
433
434 <p>As any alpha release, the code is still experimental and many things can still
435 change before the feature freeze planned for the beta release. In the following
436 weeks more alpha releases will be issued to add more functionality, polish and
437 improve the code and fix issues.</p>
438
439 <p>OpenSSL 3.0 is the next major release of OpenSSL that is currently in
440 development, and represents a major re-architecture of the internal plumbing of
441 OpenSSL. We’ve been talking about this for a while and you can read a detailed
442 description of the planned changes in our
443 <a href="https://www.openssl.org/docs/OpenSSL300Design.html">design document</a>.</p>
444
445 <p>The biggest single change is the introduction of a concept called &ldquo;<em>Providers</em>&rdquo;.
446 In OpenSSL 3.0 all cryptographic algorithms will be implemented in a provider.
447 There will be a &ldquo;<em>default</em>&rdquo; built-in provider, as well as others such as a
448 &ldquo;<em>legacy</em>&rdquo; provider to enable access to legacy algorithms and a &ldquo;<em>FIPS</em>&rdquo;
449 provider to enable access to FIPS validated algorithms. The stated target for
450 releasing this first alpha was to support “basic functionality plus basic
451 FIPS module”, after this great architectural overhaul.</p>
452
453 <p>We invite the OpenSSL community to download and test this alpha release to
454 provide early feedback, prioritizing GitHub issues and pull requests as the
455 favourite channel for contributing to the
456 <a href="https://github.com/openssl/openssl/projects/2">OpenSSL 3.0 project</a>.</p>
457
458 <p>For more details on upgrading to OpenSSL 3.0 from previous versions, as well as
459 known issues and the status of current development, we collected specific notes
460 on the <a href="https://wiki.openssl.org/index.php/OpenSSL_3.0">OpenSSL wiki</a>. We
461 strongly encourage consulting (and contributing to) this wiki entry also to
462 discover the most important changes in the upcoming OpenSSL 3.0 and how they
463 might affect you and the code you maintain.</p>
464
465 <p>We are always keen to see oldtimers and newcomers alike proposing issues, fixes
466 and contributions, not only in the form of code, but also for manpages and wiki
467 documentation. At this point, it is particularly important to also make sure
468 that the documentation for the new architecture, for the new features, and for
469 the new deprecations and their replacements, is available, complete, up-to-date
470 and sufficiently clear for external users.</p>
471
472 <p>The feedback from the community, and your involvement in testing external
473 applications and <em>ENGINEs</em> against the next version of OpenSSL and improving the
474 documentation is crucial to the continued quality of the OpenSSL Project.</p>
475 ]]></content>
476 </entry>
477
478 <entry>
479 <title type="html"><![CDATA[QUIC and OpenSSL]]></title>
480 <link href="https://www.openssl.org/blog/blog/2020/02/17/QUIC-and-OpenSSL/"/>
481 <updated>2020-02-17T12:00:00+00:00</updated>
482 <id>https://www.openssl.org/blog/blog/2020/02/17/QUIC-and-OpenSSL</id>
483 <content type="html"><![CDATA[<p>QUIC is a new protocol which the IETF talks about as
484 <a href="https://datatracker.ietf.org/doc/draft-ietf-quic-transport/">A UDP-Based Multiplexed and Secure Transport</a>,
485 and has attracted a lot of attention lately. The OpenSSL Management
486 Committee (OMC) have followed the development with interest, and we feel that we
487 owe it to the community to say where we stand on this, and on the inclusion of
488 support for this protocol in our libraries.</p>
489
490 <!-- more -->
491
492
493 <p>To begin with, nothing written here is a policy decision or similar.
494 It&rsquo;s a collective view of the current consensus within the OMC.</p>
495
496 <p>We believe that the inclusion of QUIC support in OpenSSL is extremely important
497 and there is an intention to provide it in a future version of OpenSSL. This may
498 be in the form of an API to enable TLS integration into 3rd party QUIC products,
499 or it may be in the form of a complete QUIC transport protocol implementation.</p>
500
501 <p>Whichever form our QUIC solution takes, our desire is to offer a complete
502 and stable API. This requires an API and solution design, and also that the
503 protocol itself has reached a level of stability. Judging from IETF&rsquo;s
504 <a href="https://datatracker.ietf.org/doc/draft-ietf-quic-transport/">datatracker</a>
505 at the moment of writing, QUIC is still at a point in its development
506 where it is difficult to predict what stability to expect. Based on that, and
507 our recent experience with the TLSv1.3 implementation, we consider there to
508 be a high risk that the IETF process will not have reached sufficient maturity
509 by the time that we need to freeze the OpenSSL 3.0 APIs when we release beta1
510 in <a href="https://www.openssl.org/policies/releasestrat.html">June of this year</a>.</p>
511
512 <p>The current focus of our development efforts is on <a href="https://www.openssl.org/blog/blog/2019/11/07/3.0-update/">OpenSSL 3.0</a>.
513 There is much work to be done and there are a number of alpha and beta releases
514 planned in the coming months. Whilst QUIC is very important, it is not on the
515 roadmap for the 3.0 release. We do not want to distract our development resources
516 away from that work, meaning that there is insufficient time for us to do the
517 QUIC design to the standard that we want.</p>
518
519 <p>It is our expectation that once the 3.0 release is done, QUIC will become a
520 significant focus of our effort. By this time we hope that the IETF process will
521 have reached sufficient maturity that we can design an API that is acceptable
522 for the long term.</p>
523
524 <p>We gladly accept community contributions where they align with established
525 project goals, and existing APIs. We have been <a href="https://github.com/openssl/openssl/pull/8797">offered</a>
526 a shim for interfacing other QUIC libraries on top of OpenSSL&rsquo;s libraries
527 based on one particular implementation&rsquo;s requirements. It is not a contribution
528 of QUIC support in itself. Rather, it is a bridge between an external
529 implementation that is still evolving, and the OpenSSL library.</p>
530
531 <p>After much consideration, we have collectively concluded that this would be an
532 experimental / temporary solution while waiting for a future more complete
533 solution and API, which doesn&rsquo;t align with our desire to offer a stable API. We
534 believe that there is a high risk that the requirements for that API will
535 <a href="https://github.com/openssl/openssl/pull/8797#issuecomment-583662863">change over time</a>.
536 Given our API <a href="https://www.openssl.org/policies/releasestrat.html">stability policies</a>
537 this could result in us having to support an API that is no longer optimal for a
538 very long time.</p>
539
540 <p>We believe it is more important to get a stable API that is correct for the long
541 term than an unstable API that is delivered early. Projects eager to gain
542 experience with QUIC are welcome to test the pull request in their own unstable
543 prototype builds. This may even enable and motivate some to make contributions
544 to the QUIC standardisation process. What we cannot presently commit to is a
545 <em>stable</em> QUIC API that meshes with the project&rsquo;s long-term goals.</p>
546
547 <p>Therefore, while we are pleased that OpenSSL has attracted an active contributor
548 community, and remain very supportive of, and eager for more, community
549 involvement in the project, we are <em>deferring</em> the decision on how QUIC will be
550 integrated into OpenSSL.</p>
551
552 <p>So in conclusion; QUIC is on our minds, but it will not be included in the
553 OpenSSL 3.0 release. We expect more tangible action to happen after we&rsquo;ve
554 released OpenSSL 3.0.</p>
555 ]]></content>
556 </entry>
557
558 <entry>
559 <title type="html"><![CDATA[Update on 3.0 Development, FIPS and 1.0.2 EOL]]></title>
560 <link href="https://www.openssl.org/blog/blog/2019/11/07/3.0-update/"/>
561 <updated>2019-11-07T16:00:00+00:00</updated>
562 <id>https://www.openssl.org/blog/blog/2019/11/07/3.0-update</id>
563 <content type="html"><![CDATA[<p>We have previously talked about our plans for OpenSSL 3.0 and FIPS support
564 <a href="https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/">here</a>. This blog
565 post will give an update about what has been happening since then.</p>
566
567 <!-- more -->
568
569
570 <p>There has been a huge amount of development effort that has gone into the new
571 OpenSSL 3.0 version. As of the time of writing there have been 2112 commits
572 made to the master branch of git (where all the new development work takes
573 place) since the release of OpenSSL 1.1.1 back in September 2018, and that
574 number is going up every day. To give an idea of the scale of these changes
575 that represents 8.5% of all the commits ever made to OpenSSL since it was
576 founded back in 1998!</p>
577
578 <p>OpenSSL 3.0 represents a major re-architecture of the internal plumbing of
579 OpenSSL. We&rsquo;ve been talking about this for a while and you can read a detailed
580 description of the planned changes in our
581 <a href="https://www.openssl.org/docs/OpenSSL300Design.html">design document</a>.</p>
582
583 <p>The biggest single change is the introduction of a concept called &ldquo;Providers&rdquo;.
584 In OpenSSL 3.0 all cryptographic algorithms will be implemented in a provider.
585 There will be a &ldquo;default&rdquo; built-in provider, as well as others such as a
586 &ldquo;legacy&rdquo; provider to enable access to legacy algorithms and a &ldquo;FIPS&rdquo; provider
587 to enable access to FIPS validated algorithms.</p>
588
589 <p>There has been significant progress towards implementing the changes in that
590 design document. The three providers I described above are already present and
591 (almost) all ciphers and digests have been migrated into them as well as
592 numerous other algorithms. Migration of the various asymmetric algorithms is
593 currently in progress. For those interested in following the current
594 active development you can look at the currently active pull requests
595 <a href="https://github.com/openssl/openssl/projects/2">here</a>.</p>
596
597 <p>Our original timeline had us aiming to be code complete by the end of this year
598 (2019), after which we would do a series of beta releases in parallel with the
599 FIPS lab doing its work. The final release of 3.0 was expected in early Q2 2020
600 with the actual validation of the FIPS module occurring sometime after that.</p>
601
602 <p>In spite of the extensive progress made there is still much left to do. It has
603 become clear that we will not be able to achieve those original timeline
604 aspirations. We are now not expecting code completion to occur until the end of
605 Q2 2020 with a final release in early Q4 2020.</p>
606
607 <p>We still expect the upgrade path from OpenSSL 1.1.1 to OpenSSL 3.0 to be
608 relatively easy for most applications. In most cases applications will simply
609 need to recompile in order to work with the new version. However, some changes
610 may be required in order to benefit from the new features being introduced in
611 OpenSSL 3.0 - for example to use algorithms from one of the new providers. In
612 the simplest cases these changes might just be configuration file updates. In
613 other cases code changes will be required.</p>
614
615 <p>The changes required for existing users of OpenSSL 1.0.2 to upgrade to OpenSSL
616 3.0 are more significant. For existing users of OpenSSL 1.0.2 we recommend
617 upgrading to our newest LTS (Long Term Support) release 1.1.1, in order to
618 ease the future migration to OpenSSL 3.0.</p>
619
620 <p>Note that as previously announced OpenSSL 1.0.2 will be End Of Life at the end
621 of this year. This means there will not be any further public updates or
622 security fixes to the 1.0.2 branch from then. This gives another strong reason
623 for existing 1.0.2 users to upgrade to 1.1.1 as soon as possible.</p>
624
625 <p>Users of the old FIPS Object Module (OpenSSL FOM 2.0) are not able to use that
626 with OpenSSL 1.1.1 (it only works with OpenSSL 1.0.2). We are expecting no
627 further updates to the FOM 2.0 and it has not been receiving any fixes for some
628 time. There was always expected to be a gap between the EOL of OpenSSL 1.0.2 and
629 OpenSSL 3.0. Unfortunately with the new expected delivery dates for OpenSSL 3.0
630 the gap has got bigger. Users of the OpenSSL FOM 2.0 should plan their response
631 to that gap. One option is to take out a premium
632 <a href="https://www.openssl.org/support/contracts.html">support contract</a> which will
633 continue to offer security fixes for the 1.0.2 branch (although not the FOM) for
634 the foreseeable future. You can contact us at <a href="&#109;&#x61;&#105;&#x6c;&#116;&#111;&#58;&#111;&#x73;&#102;&#45;&#x63;&#111;&#x6e;&#x74;&#97;&#x63;&#116;&#x40;&#x6f;&#112;&#101;&#110;&#115;&#115;&#x6c;&#x2e;&#111;&#114;&#x67;">&#x6f;&#115;&#102;&#x2d;&#x63;&#111;&#x6e;&#x74;&#97;&#x63;&#116;&#x40;&#111;&#112;&#101;&#x6e;&#115;&#x73;&#x6c;&#46;&#111;&#x72;&#103;</a> for
635 further details on that option.</p>
636
637 <p>In summary there has been much development activity over the last year and much
638 remains to be done. I&rsquo;d encourage anyone who wants to help out to start looking
639 at our github pages. A good place to start is the list of issues. We are
640 always keen to see newcomers proposing fixes for those issues. If you want to
641 take a sneek peek at the new code then just download the latest code from the
642 master git branch and have a go with it. We&rsquo;d be particularly keen to hear about
643 any issues that you might encounter.</p>
644 ]]></content>
645 </entry>
646
647 <entry>
648 <title type="html"><![CDATA[Face to Face: Committer's Day]]></title>
649 <link href="https://www.openssl.org/blog/blog/2019/05/23/f2f-committers-day/"/>
650 <updated>2019-05-23T17:15:00+00:00</updated>
651 <id>https://www.openssl.org/blog/blog/2019/05/23/f2f-committers-day</id>
652 <content type="html"><![CDATA[<p>At the Face to Face meeting held on the occasion of the <a href="https://icmconference.org">ICMC19 Conference</a>
653 in Vancouver, a novelty was introduced: For the last day of the meeting all
654 committers were invited to participate, either personally or remotely via video conference.</p>
655
656 <!-- more -->
657
658
659 <p>Three of us committers (Paul, Nicola, Matthias) came to Vancouver for the conference, so
660 we were able to participate in person, Bernd (DE) and Shane (AU)
661 joined us remotely.</p>
662
663 <p><img src="https://www.openssl.org/blog/images/committers-day-2019.jpg"></p>
664
665 <p>Paul Yang, Matthias St. Pierre, Tim Hudson, Matt Caswell, Richard Levitte, Nicola Tuveri (from left to right)</p>
666
667 <p>The group was completed by the OMC members Paul Dale (AU), Kurt Roeckx (BE), Mark Cox (UK).</p>
668
669 <p>While Paul Yang had already met the team members during their <a href="https://www.openssl.org/blog/blog/2017/08/28/china">visit to China in 2017</a>,
670 for Nicola and me it was the first personal encounter. We were both curious and a little bit
671 anxious to find out how we would be received by the long time team members. But it turned out
672 that our worries were unfounded: after passing Tim Hudson&rsquo;s vegemite survival test (see below),
673 we were both cordially accepted by the team.</p>
674
675 <p>Matt started the meeting with a detailed introduction and a status report about the architectural
676 changes to the library and the ongoing FIPS development. After that, we embarked on a lively and
677 fruitful discussion. The outcome of the meeting is a different story and will be reported elsewhere.
678 For us committers, it was an interesting and instructive experience to see how these OMC F2F meetings
679 took place and how actions were planned and decisions made.</p>
680
681 <p>But even more important than anything else was the fact that we were able to get to know each other
682 and that we all had a great time together. In this respect the meeting was so successful, that we
683 decided to have online video conference meetings on a regular base in order to improve our team
684 interaction and collaboration.</p>
685
686 <p><img src="https://www.openssl.org/blog/images/nicola-vegemite.jpg"></p>
687
688 <p><img src="https://www.openssl.org/blog/images/matthias-vegemite.jpg"></p>
689 ]]></content>
690 </entry>
691
692 <entry>
693 <title type="html"><![CDATA[New Committers]]></title>
694 <link href="https://www.openssl.org/blog/blog/2019/05/20/committers/"/>
695 <updated>2019-05-20T12:00:00+00:00</updated>
696 <id>https://www.openssl.org/blog/blog/2019/05/20/committers</id>
697 <content type="html"><![CDATA[<p>Following on from our additions to the committers <a href="https://www.openssl.org/blog/blog/2018/08/22/updates/">last year</a>,
698 the <a href="https://www.openssl.org/community/omc.html">OpenSSL Management Committee</a> has now added four new
699 <a href="https://www.openssl.org/community/committers.html">Committers</a>.</p>
700
701 <!-- more -->
702
703
704 <p>The latest additions to the committers are:</p>
705
706 <ul>
707 <li><a href="https://github.com/beldmit">Dmitry Belyavskiy</a></li>
708 <li><a href="https://github.com/slontis">Shane Lontis</a></li>
709 <li><a href="https://github.com/t8m">Tomáš Mráz</a></li>
710 <li><a href="https://github.com/p-steuer">Patrick Steuer</a></li>
711 </ul>
712
713
714 <p>What this means for the OpenSSL community is that there is now a larger group
715 of active developers who have the ability to review and commit code to our
716 source code repository. These new committers will help the existing
717 committers with our review process (i.e., their reviews count towards approval)
718 which we anticipate will help us keep on top of
719 the github <a href="https://github.com/openssl/openssl/issues">issues</a>
720 and <a href="https://github.com/openssl/openssl/pulls">pull request</a> queues.</p>
721
722 <p>As always, we welcome comments on submissions and technical reviews of
723 <a href="https://github.com/openssl/openssl/pulls">pull requests</a> from anyone in the community.</p>
724
725 <p>Note: All submissions must be reviewed and approved by at least two committers,
726 one of whom must also be an OMC member as described in
727 the <a href="https://www.openssl.org/policies/omc-bylaws.html">project bylaws</a></p>
728 ]]></content>
729 </entry>
730
731 <entry>
732 <title type="html"><![CDATA[OpenSSL 3.0 and FIPS Update]]></title>
733 <link href="https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/"/>
734 <updated>2019-02-13T10:30:00+00:00</updated>
735 <id>https://www.openssl.org/blog/blog/2019/02/13/FIPS-update</id>
736 <content type="html"><![CDATA[<p>As <a href="https://www.openssl.org/blog/blog/2018/09/25/fips/">mentioned</a> in a previous
737 blog post, OpenSSL team members met with various representatives of the FIPS
738 sponsor organisations back in September last year to discuss design and planning
739 for the new FIPS module development project.</p>
740
741 <p>Since then there has been much design work taking place and we are now able to
742 publish the draft design documentation. You can read about how we see the longer
743 term architecture of OpenSSL changing in the future
744 <a href="https://www.openssl.org/docs/OpenSSLStrategicArchitecture.html">here</a> and you
745 can read about our specific plans for OpenSSL 3.0 (our next release which will
746 include a FIPS validated module)
747 <a href="https://www.openssl.org/docs/OpenSSL300Design.html">here</a>.</p>
748
749 <!-- more -->
750
751
752 <p>OpenSSL 3.0 is a major release and will be a significant change to the internal
753 architecture of OpenSSL. We plan to keep impacts on existing end user
754 applications to an absolute minimum with the intention that the vast majority of
755 existing well-behaved applications will just need to be recompiled. No
756 deprecated APIs will be removed in this release.</p>
757
758 <p>The biggest change will be the introduction of a new concept known as
759 <em>Providers</em>. These can be seen as a replacement for the existing ENGINE
760 interface and will enable much more flexibility for implementors. libcrypto
761 gives applications access to a set of cryptographic algorithms, while different
762 Providers may have different implementations of those algorithms.</p>
763
764 <p>Out-of-the-box OpenSSL will come with a set of Providers available. For example
765 the &ldquo;default&rdquo; Provider will implement all of the most commonly used algorithms
766 available in OpenSSL today. There will be a &ldquo;legacy&rdquo; Provider that implements
767 legacy cryptographic algorithms and a FIPS Provider that implements FIPS
768 validated algorithms. Existing engines will still work (after a recompile) and
769 will be made available via both the old ENGINE APIs as well as a Provider
770 compatibility layer.</p>
771
772 <p>The new design incorporates the FIPS module into main line OpenSSL. It will no
773 longer be a separate download and support periods will also be aligned. It will
774 of course be possible to build OpenSSL with or without the FIPS module depending
775 on your own individual circumstances and requirements.</p>
776
777 <p>The FIPS module version number will be aligned with the main OpenSSL version
778 number. OpenSSL 3.0.0 will incorporate the 3.0.0 FIPS module. Not every release
779 of OpenSSL will necessarily lead to an update in the FIPS module version number
780 so there may be &ldquo;gaps&rdquo;. For example OpenSSL 3.0.1 might still provide and work
781 with the 3.0.0 module.</p>
782
783 <p>New APIs will be introduced to give applications greater flexibility in the
784 selection of algorithm implementations. Of course support will be maintained for
785 existing APIs so applications don&rsquo;t need to use the new APIs if they don&rsquo;t want
786 to. For example applications will be able to set different algorithm selection
787 criteria for different SSL_CTXs. This might be used to enforce selection of FIPS
788 validated algorithms for one SSL_CTX, while allowing another SSL_CTX to use
789 default implementations.</p>
790
791 <p>There is much still to be done to make this new OpenSSL design a reality.
792 However with the publication of these design documents we are encouraged to see
793 that pull requests are already starting to come in to make the necessary changes
794 to the code. We expect the coming months to be very active amongst the
795 development community as we head towards alpha and beta releases later on this
796 year.</p>
797 ]]></content>
798 </entry>
799
800 <entry>
801 <title type="html"><![CDATA[Celebrating 20 Years of OpenSSL]]></title>
802 <link href="https://www.openssl.org/blog/blog/2018/12/20/20years/"/>
803 <updated>2018-12-20T12:00:00+00:00</updated>
804 <id>https://www.openssl.org/blog/blog/2018/12/20/20years</id>
805 <content type="html"><![CDATA[<p>20 years ago, on the 23rd December 1998, the first version of OpenSSL was
806 released. OpenSSL was not the original name planned for the project but it was
807 changed over just a few hours before the site went live. Let’s take a look at
808 some of the early history of OpenSSL as some of the background has not been
809 documented before.</p>
810
811 <!-- more -->
812
813
814 <p>Back in the late 1990’s, Eric Young and Tim Hudson were well known for their
815 work on the open source SSLeay library. SSLeay was widely used with Apache and
816 (then) third party SSL modules to create open source secure web servers. In
817 1998 they both worked for C2Net, enhancing SSLeay and the products using
818 it. C2Net was known for its flagship product, the Stronghold web server, a
819 packaged and compiled product built on open source software with both support
820 and, crucially, the ability to be used world-wide with strong encryption. It
821 seems trivial now but back then cryptography products exported from the US like
822 web servers and browsers were hobbled to use limited weak cryptography.</p>
823
824 <p>Eric and Tim had decided to leave C2Net to join RSA, a creator of a commercial
825 SSL toolkit, so the future of SSLeay was unclear. This led to the genesis of
826 the OpenSSL project through a discussion I had with Ralf Engelschall, a fellow
827 core Apache developer, on 14th October 1998 in San Francisco at the <a href="https://www.flickr.com/photos/iamamoose/sets/1381277">first ever ApacheCon</a>. We picked up
828 the discussion a few months later, set up a mailing list on December 16th, and
829 invited Stephen Henson, an SSLeay expert, to participate in what we then called
830 OpenTLS. Ben Laurie, a core Apache developer and author of Apache-SSL, also
831 independently <a href="https://marc.info/?l=ssl-users&amp;m=91398882721702&amp;w=2">announced his intention</a> to start a new
832 version of SSLeay a couple of days later.</p>
833
834 <p>Ralf took the source code from the public SSLeay versions 0.8.1 and 0.9.0b and
835 the unreleased 0.9.1b version from C2Net and imported them into the OpenTLS CVS
836 repository. We did some cleanup work on the files, added some patches from
837 ourselves, and added some well known patches from the community to form the
838 0.9.1c version.</p>
839
840 <p>At the <a href="https://github.com/openssl/openssl/commit/f1c236f849d9799a5de0ad1f6c64b33291f60c84">very last minute</a>,
841 just before going public, we changed from using the OpenTLS name to OpenSSL:
842 the upcoming TLS protocol RFC had not yet been published and the acronym was
843 relatively unknown at that time whereas the SSL acronym was widely recognised
844 and so using SSL in the name would help users understand the transition from
845 using SSLeay to OpenSSL. We had fortunately reserved both domain names.</p>
846
847 <p>On the 23rd December 1998 we opened up the
848 <a href="http://www.openssl.org">www.openssl.org</a> site and released the OpenSSL-0.9.1c
849 version and source code repository.</p>
850
851 <p>Throughout that busy week we were communicating with Ben and Stephen to align
852 and merge our projects, and so shortly after the Christmas holiday we made the
853 <a href="https://marc.info/?l=ssl-users&amp;m=91566086807308&amp;w=2">full project release
854 announcement</a>. The initial
855 project team was therefore comprised of Ben Laurie, Paul Sutton, Ralf
856 Engelschall, Stephen Henson and myself, Mark Cox. All but Stephen Henson were
857 core developers of the Apache HTTP Server.</p>
858
859 <p>For the first 15 years, OpenSSL membership was mostly a small collection of
860 individuals working on a part time basis and the membership fluctuated and
861 changed through those years. Approximately 5 years ago we expanded the group
862 and introduced formal policies. As of today we have a structure where a <a href="https://www.openssl.org/community/committers.html">team of committers</a> are able to
863 review and commit changes to the code, and a <a href="https://www.openssl.org/community/omc.html">management committee</a> oversee the
864 project. OpenSSL is funded mostly through the generous donations of
865 <a href="https://www.openssl.org/support/acks.html">sponsors</a>. We also have paid
866 support contracts and occasionally take on contracts to develop certain new
867 functionality. We use this funding primarily to pay fellows to work full time
868 on the project. The fellows maintain the infrastructure, fix bugs and security
869 issues, review patches, and much more (you can see what they are up to from
870 their monthly reports sent to the <a href="https://mta.openssl.org/pipermail/openssl-project/">openssl-project mailing list</a>). Many <a href="https://www.openssl.org/community/thanks.html">companies also donate staff time</a> to work
871 on OpenSSL.</p>
872
873 <p>The 20th year looks to be an exciting one, with a major change to the <a href="https://www.openssl.org/blog/blog/2018/11/28/version/">version number scheme</a>, the
874 switch to the Apache License 2.0, and a new <a href="https://www.openssl.org/blog/blog/2018/09/25/fips/">FIPS validation project</a> just for
875 starters. And although all the versions of SSL are now deprecated, it’s not
876 likely we’ll <a href="https://github.com/openssl/openssl/issues/6384">rebrand back to OpenTLS</a> any time soon.</p>
877
878 <p><img src="https://www.openssl.org/blog/images/2018-12-f2f.png"></p>
879
880 <p>Picture showing OpenSSL Management Committee during a face to face meeting in
881 front of Edinburgh Castle, November 2018. Left to right: Paul Dale, Kurt
882 Roeckx, Richard Levitte, Matt Caswell, Mark Cox, Tim Hudson. Viktor Dukhovni
883 (not pictured) joined us virtually.</p>
884 ]]></content>
885 </entry>
886
887 <entry>
888 <title type="html"><![CDATA[The Holy Hand Grenade of Antioch]]></title>
889 <link href="https://www.openssl.org/blog/blog/2018/11/28/version/"/>
890 <updated>2018-11-28T12:00:00+00:00</updated>
891 <id>https://www.openssl.org/blog/blog/2018/11/28/version</id>
892 <content type="html"><![CDATA[<p>The OpenSSL Management Committee has been looking at the versioning scheme that
893 is currently in use. Over the years we&rsquo;ve received plenty of feedback about the
894 &ldquo;uniqueness&rdquo; of this scheme, and it does cause some confusion for some users. We
895 would like to adopt a more typical version numbering approach.</p>
896
897 <p>The current versioning scheme has this format:</p>
898
899 <p>MAJOR.MINOR.FIX[PATCH]</p>
900
901 <p>The new scheme will have this format:</p>
902
903 <p>MAJOR.MINOR.PATCH</p>
904
905 <p>In practical terms our &ldquo;letter&rdquo; patch releases become patch numbers and &ldquo;fix&rdquo;
906 is dropped from the concept. In future, API/ABI compatibility will only be
907 guaranteed for the same MAJOR version number. Previously we guaranteed
908 API/ABI compatibility across the same MAJOR.MINOR combination. This more closely
909 aligns with the expectations of users who are familiar with semantic versioning.
910 We are not at this stage directly adopting semantic versioning because it would
911 mean changing our current LTS policies and practices.</p>
912
913 <p>The current 1.1.1 and 1.0.2 versioning scheme will remain unchanged.</p>
914
915 <p>The current development version (master branch) will be identified as version
916 3.0.0. The OpenSSL FIPS module currently under development will also follow this
917 versioning scheme. We are skipping the 2.0.0 major version because the previous
918 OpenSSL FIPS module has already used this number.</p>
919
920 <p>OpenSSL version 3.0.0 will be the first version that we release under the Apache
921 License 2.0. We will not be applying the Apache License to earlier releases of
922 OpenSSL.</p>
923 ]]></content>
924 </entry>
925
926 <entry>
927 <title type="html"><![CDATA[FIPS 140-2: Forward Progress]]></title>
928 <link href="https://www.openssl.org/blog/blog/2018/09/25/fips/"/>
929 <updated>2018-09-25T12:00:00+00:00</updated>
930 <id>https://www.openssl.org/blog/blog/2018/09/25/fips</id>
931 <content type="html"><![CDATA[<p>The OpenSSL Management Committee (OMC) on behalf of the OpenSSL Project would
932 like to formally express its thanks to the following organisations
933 for agreeing to sponsor the next
934 FIPS validation effort: Akamai Technologies, Blue Cedar, NetApp, Oracle, VMware.</p>
935
936 <p>Four weeks ago, the OpenSSL team gathered with many of the organisations
937 sponsoring the next FIPS module for a face-to-face meeting in Brisbane,
938 Australia.</p>
939
940 <p>We got a great deal accomplished during that week. Having most of
941 the fips-sponsor organisations in the same location helps ensure that
942 we are all on the same page for the decisions we need to make going forward.</p>
943
944 <!-- more -->
945
946
947 <p>The fips-sponsor gathering (hosted by Oracle, Brisbane) involved a diverse
948 group of people:</p>
949
950 <p><img src="https://www.openssl.org/blog/images/2018-08-27-fips-sponsors.png" title="" ></p>
951
952 <p>It has been more than seven years since the commencement of the previous
953 FIPS140 module work and many things have changed during that time, both
954 in terms of requirements of the Cryptographic Module Validation Program
955 (CMVP) and the OpenSSL code base.</p>
956
957 <p>For the current validation effort, input and assistance from a small
958 group (the five fips-sponsors) is essential to achieving the outcomes of
959 the project in this area - a validated module that is usable
960 by itself and can also form the foundation for other companies to perform
961 their own validations for any areas where there are specific requirements
962 outside the general scope.</p>
963
964 <p>As the project moves from high-level design to detailed design,
965 prototyping, development, testing, documentation and quality assurance,
966 we plan to make information available to the OpenSSL community for review
967 and comment - as the next FIPS140 module will be substantially different
968 to the previous approaches.</p>
969
970 <p>We are mindful of the end-of-life date for OpenSSL-1.0.2 (31-Dec-2019)
971 and the end-of-life (sunset date) of the existing OpenSSL FIPS Object
972 Object (29-Jan-2022) and our objective remains to have a validated
973 cryptographic module in place well before 31-Dec-2019.</p>
974 ]]></content>
975 </entry>
976
977 <entry>
978 <title type="html"><![CDATA[OpenSSL 1.1.1 Is Released]]></title>
979 <link href="https://www.openssl.org/blog/blog/2018/09/11/release111/"/>
980 <updated>2018-09-11T12:00:00+00:00</updated>
981 <id>https://www.openssl.org/blog/blog/2018/09/11/release111</id>
982 <content type="html"><![CDATA[<p>After two years of work we are excited to be releasing our latest version today -
983 OpenSSL 1.1.1. This is also our new Long Term Support (LTS) version and so we
984 are committing to support it for at least five years.</p>
985
986 <p>OpenSSL 1.1.1 has been a huge team effort with nearly 5000 commits having been
987 made from over 200 individual contributors since the release of OpenSSL 1.1.0.
988 These statistics just illustrate the amazing vitality and diversity of the
989 OpenSSL community. The contributions didn&rsquo;t just come in the form of commits
990 though. There has been a great deal of interest in this new version so thanks
991 needs to be extended to the large number of users who have downloaded the beta
992 releases to test them out and report bugs.</p>
993
994 <!-- more -->
995
996
997 <p>The headline new feature is TLSv1.3. This new version of the Transport Layer
998 Security (formerly known as SSL) protocol was published by the IETF just one
999 month ago as RFC8446. This is a major rewrite of the standard and introduces
1000 significant changes, features and improvements which have been reflected in the
1001 new OpenSSL version.</p>
1002
1003 <p>What&rsquo;s more is that OpenSSL 1.1.1 is API and ABI compliant with OpenSSL 1.1.0 so
1004 most applications that work with 1.1.0 can gain many of the benefits of TLSv1.3
1005 simply by dropping in the new OpenSSL version. Since TLSv1.3 works very
1006 differently to TLSv1.2 though there are a few caveats that may impact a
1007 minority of applications. See the
1008 <a href="https://wiki.openssl.org/index.php/TLS1.3">TLSv1.3 page</a> on the OpenSSL wiki
1009 for more details.</p>
1010
1011 <p>Some of the benefits of TLSv1.3 include:</p>
1012
1013 <ul>
1014 <li>Improved connection times due to a reduction in the number of round trips
1015 required between the client and server</li>
1016 <li>The ability, in certain circumstances, for clients to start sending encrypted
1017 data to the server straight away without any round trips with the server
1018 required (a feature known as 0-RTT or &ldquo;early data&rdquo;).</li>
1019 <li>Improved security due to the removal of various obsolete and insecure
1020 cryptographic algorithms and encryption of more of the connection handshake</li>
1021 </ul>
1022
1023
1024 <p>Other features in the 1.1.1 release include:</p>
1025
1026 <ul>
1027 <li>Complete rewrite of the OpenSSL random number generator to introduce the
1028 following capabilities
1029
1030 <ul>
1031 <li>The default RAND method now utilizes an AES-CTR DRBG according to NIST
1032 standard SP 800-90Ar1.</li>
1033 <li>Support for multiple DRBG instances with seed chaining.</li>
1034 <li>There is a public and private DRBG instance.</li>
1035 <li>The DRBG instances are fork-safe.</li>
1036 <li>Keep all global DRBG instances on the secure heap if it is enabled.</li>
1037 <li>The public and private DRBG instance are per thread for lock free operation</li>
1038 </ul>
1039 </li>
1040 <li>Support for various new cryptographic algorithms including:
1041
1042 <ul>
1043 <li>SHA3</li>
1044 <li>SHA512/224 and SHA512/256</li>
1045 <li>EdDSA (including Ed25519 and Ed448)</li>
1046 <li>X448 (adding to the existing X25519 support in 1.1.0)</li>
1047 <li>Multi-prime RSA</li>
1048 <li>SM2</li>
1049 <li>SM3</li>
1050 <li>SM4</li>
1051 <li>SipHash</li>
1052 <li>ARIA (including TLS support)</li>
1053 </ul>
1054 </li>
1055 <li>Signficant Side-Channel attack security improvements</li>
1056 <li>Maximum Fragment Length TLS extension support</li>
1057 <li>A new STORE module, which implements a uniform and URI based reader of stores
1058 that can contain keys, certificates, CRLs and numerous other objects.</li>
1059 </ul>
1060
1061
1062 <p>Since 1.1.1 is our new LTS release we are strongly advising all users to upgrade
1063 as soon as possible. For most applications this should be straight forward if
1064 they are written to work with OpenSSL 1.1.0. Since OpenSSL 1.1.0 is not an LTS
1065 release it will start receiving security fixes only with immediate affect as per
1066 our previous
1067 <a href="https://www.openssl.org/blog/blog/2018/05/18/new-lts/">announcement</a> and as
1068 published in our
1069 <a href="https://www.openssl.org/policies/releasestrat.html">release strategy</a>. It will
1070 cease receiving all support in one years time.</p>
1071
1072 <p>Our previous LTS release (OpenSSL 1.0.2) will continue to receive full support
1073 until the end of this year. After that it will receive security fixes only. It
1074 will stop receiving all support at the end of 2019. Users of that release are
1075 strongly advised to upgrade to OpenSSL 1.1.1.</p>
1076
1077 <p>The OpenSSL team will now be moving our focus to the next release which will see
1078 us developing a new FIPS module.</p>
1079 ]]></content>
1080 </entry>
1081
1082 <entry>
1083 <title type="html"><![CDATA[New OMC Member and New Committers]]></title>
1084 <link href="https://www.openssl.org/blog/blog/2018/08/22/updates/"/>
1085 <updated>2018-08-22T12:00:00+00:00</updated>
1086 <id>https://www.openssl.org/blog/blog/2018/08/22/updates</id>
1087 <content type="html"><![CDATA[<p>We first announced <a href="https://www.openssl.org/blog/blog/2017/06/13/committers/">last year</a>
1088 the <a href="https://www.openssl.org/community/omc.html">OpenSSL Management Committee</a>
1089 and separate <a href="https://www.openssl.org/community/committers.html">Committers</a> groups
1090 aimed at enabling greater involvement from the community.</p>
1091
1092 <p>We have now added a new OMC member and two new committers.</p>
1093
1094 <!-- more -->
1095
1096
1097 <p>The latest addition to the OMC is:</p>
1098
1099 <ul>
1100 <li><a href="https://github.com/paulidale">Paul Dale</a></li>
1101 </ul>
1102
1103
1104 <p>The latest additions to the committers are:</p>
1105
1106 <ul>
1107 <li><a href="https://github.com/InfoHunter">Paul Yang</a></li>
1108 <li><a href="https://github.com/romen">Nicola Tuveri</a></li>
1109 </ul>
1110
1111
1112 <p>What this means for the OpenSSL community is that there is now a larger group
1113 of active developers who have the ability to review and commit code to our
1114 source code repository. These new committers will help the existing
1115 committers with our review process (i.e., their reviews count towards approval)
1116 which we anticipate will help us keep on top of
1117 the github <a href="https://github.com/openssl/openssl/issues">issues</a>
1118 and <a href="https://github.com/openssl/openssl/pulls">pull request</a> queues.</p>
1119
1120 <p>As always, we welcome comments on submissions and technical reviews of
1121 <a href="https://github.com/openssl/openssl/pulls">pull requests</a> from anyone in the community.</p>
1122
1123 <p>Note: All submissions must be reviewed and approved by at least two committers,
1124 one of whom must also be an OMC member as described in
1125 the <a href="https://www.openssl.org/policies/bylaws.html">project bylaws</a></p>
1126
1127 <p>As well as the above additions to our team, Rich Salz has now left his
1128 roles as OpenSSL Management Committee member and OpenSSL committer. Rich
1129 has had a long standing association with the project and we would like
1130 to thank him for his many significant contributions over the years.</p>
1131 ]]></content>
1132 </entry>
1133
1134 <entry>
1135 <title type="html"><![CDATA[New LTS Release]]></title>
1136 <link href="https://www.openssl.org/blog/blog/2018/05/18/new-lts/"/>
1137 <updated>2018-05-18T06:00:00+00:00</updated>
1138 <id>https://www.openssl.org/blog/blog/2018/05/18/new-lts</id>
1139 <content type="html"><![CDATA[<p>Back around the end of 2014 we posted our
1140 <a href="https://www.openssl.org/policies/releasestrat.html">release strategy</a>. This
1141 was the first time we defined support timelines for our releases, and added
1142 the concept of an LTS (long-term support) release. At our OMC meeting
1143 earlier this month, we picked our next LTS release. This post walks through
1144 that announcement, and tries to explain all the implications of it.</p>
1145
1146 <!-- more -->
1147
1148
1149 <p>Once an official release is made, it then enters support mode.
1150 No new features are added &ndash; those only go into the next release.
1151 In rare cases we will make an exception; for example, we said that if
1152 any accessors or setters are missing in 1.1.0, because of structures being
1153 made opaque, we would treat that as a bug.</p>
1154
1155 <p>Support itself is divided into three phases. First, there is active and ongoing
1156 support. All bugs are appropriate for this phase. This happens once the release
1157 is published. Next is the security-only phase, where we only fix security
1158 bugs, which will typically have a CVE associated with them. This happens for
1159 the final year of support. Finally, there is EOL (end of life), where the
1160 project no longer provides any support or fixes.</p>
1161
1162 <p>In the typical case, a release is supported for at least two years, which
1163 means one year of fixes and one year of security-only fixes.
1164 Some releases, however, are designated as LTS releases.
1165 They are supported for at least five years.
1166 We will specify an LTS release at least every four years, which gives the
1167 community at least a year to migrate.</p>
1168
1169 <p>Our current LTS release is 1.0.2, and it will be supported until the end
1170 of 2019. During that last year it will only receive security fixes.
1171 Although we are extended 1.1.0 support, we explicitly decided not to do
1172 it again, for either release.</p>
1173
1174 <p>Our next LTS release will be 1.1.1 which is currently in beta.
1175 As long as the release is out before the end of 2018, there is more than a
1176 year to migrate. (We&rsquo;re confident it will be out before then, of course.)
1177 We encourage everyone to start porting to the OpenSSL master branch.</p>
1178
1179 <p>The 1.1.0 release will be supported for one year after 1.1.1 is released.
1180 And again, during that final year we will only provide security fixes.
1181 Fortunately, 1.1.0 is ABI compatible with 1.1.1, so moving up should not
1182 be difficult.
1183 Our <a href="https://wiki.openssl.org/index.php/TLS1.3">TLS 1.3 wiki page</a> has some
1184 more details around the impact of TLS 1.3 support.</p>
1185
1186 <p>Finally, this has an impact on the OpenSSL FIPS module,
1187 <a href="https://csrc.nist.gov/projects/cryptographic-module-validation-program/Certificate/1747">#1747</a>.
1188 That module is valid until the January 29, 2022.
1189 This means that for the final two-plus years of its validity, we will
1190 not be supporting the release on which the module is based.
1191 We have already stated that we do not support the module itself; this
1192 adds to the burden that vendors will have to take on.
1193 On the positive side, we&rsquo;re committed to a new FIPS module, it will be
1194 based on the current codebase, and we think we can get it done fairly
1195 quickly.</p>
1196 ]]></content>
1197 </entry>
1198
1199 <entry>
1200 <title type="html"><![CDATA[Changing the Guiding Principles in Our Security Policy]]></title>
1201 <link href="https://www.openssl.org/blog/blog/2018/05/16/security-policy/"/>
1202 <updated>2018-05-16T21:00:00+00:00</updated>
1203 <id>https://www.openssl.org/blog/blog/2018/05/16/security-policy</id>
1204 <content type="html"><![CDATA[<blockquote><p>&ldquo;That we remove &#8220;We strongly believe that the right to advance patches/info
1205 should not be based in any way on paid membership to some forum. You can not
1206 pay us to get security patches in advance.&rdquo; from the security policy and Mark
1207 posts a blog entry to explain the change including that we have no
1208 current such service.&#8221;</p></blockquote>
1209
1210 <p>At the OpenSSL Management Committee meeting earlier this month we <a href="https://mta.openssl.org/pipermail/openssl-project/2018-May/000724.html">passed the vote above</a> to remove a section our <a href="https://www.openssl.org/policies/secpolicy.html">security policy</a>. Part of that vote
1211 was that I would write this blog post to explain why we made this change.</p>
1212
1213 <p>At each face to face meeting we aim to ensure that our policies still match the
1214 view of the current membership committee at that time, and will vote to change
1215 those that don&rsquo;t.</p>
1216
1217 <p>Prior to 2018 our Security Policy used to contain a lot of background
1218 information on why we selected the policy we did, justifying it and adding lots
1219 of explanatory detail. We included details of things we&rsquo;d tried before and
1220 things that worked and didn&rsquo;t work to arrive at our conclusion. At our <a href="https://www.openssl.org/blog/blog/2018/01/18/f2f-london/">face to face meeting in London</a> at the end of
1221 2017 we decided to remove a lot of the background information and stick to
1222 explaining the policy simply and concisely. <a href="https://github.com/openssl/web/commit/ac747af201144b372b8b6145d2219fae6bccd958#diff-f95ee49dc0f0677c2257d8432520bc4b">I split out</a>
1223 what were the guiding principles from the policy into their own list.</p>
1224
1225 <p>OpenSSL has some full-time fellows who are paid from various revenue sources
1226 coming into OpenSSL including sponsorship and support contracts. We&rsquo;ve
1227 discussed having the option in the future to allow us to share patches for
1228 security issues in advance to these support contract customers. We already
1229 share serious issues a little in advance with some OS vendors (and this is
1230 still a principle in the policy to do so), and this policy has helped ensure
1231 that the patches and advisory get an extra level of testing before being
1232 released.</p>
1233
1234 <p>Thankfully there are relatively few serious issues in OpenSSL these days; the last worse
1235 than <a href="https://www.openssl.org/policies/secpolicy.html#high">Moderate severity</a>
1236 being in <a href="https://www.openssl.org/news/vulnerabilities.html#CVE-2017-3733">February 2017</a>.</p>
1237
1238 <p>In the vote text we wrote that we have &ldquo;no current such service&rdquo; and neither do
1239 we have any plan right now to create such a service. But we allow ourselves to
1240 consider such a possibility in the future now that this principle, which no longer
1241 represents the view of the OMC, is removed.</p>
1242 ]]></content>
1243 </entry>
1244
1245 <entry>
1246 <title type="html"><![CDATA[Seeking Last Group of Contributors]]></title>
1247 <link href="https://www.openssl.org/blog/blog/2018/03/01/last-license/"/>
1248 <updated>2018-03-01T06:00:00+00:00</updated>
1249 <id>https://www.openssl.org/blog/blog/2018/03/01/last-license</id>
1250 <content type="html"><![CDATA[<p>The following is a press release that we just put out about how finishing
1251 off our relicensing effort. For the impatient, please see
1252 <a href="https://license.openssl.org/trying-to-find">https://license.openssl.org/trying-to-find</a>
1253 to help us find the last people; we want to change the license with our
1254 next release, which is currently in Alpha, and tentatively set for May.</p>
1255
1256 <p>For background, you can see all posts in the
1257 <a href="https://www.openssl.org/blog/blog/categories/license/">license category</a>.</p>
1258
1259 <p>One copy of the press release is at
1260 <a href="https://www.prnewswire.com/news-releases/openssl-seeking-last-group-of-contributors-300607162.html">https://www.prnewswire.com/news-releases/openssl-seeking-last-group-of-contributors-300607162.html</a>.</p>
1261
1262 <!-- more -->
1263
1264
1265 <h2>OpenSSL Seeking Last Group of Contributors</h2>
1266
1267 <h2>Looking for programmers who contributed code to the OpenSSL project</h2>
1268
1269 <p>The OpenSSL project,
1270 [<a href="https://www.openssl.org">https://www.openssl.org</a>] (<a href="https://www.openssl.org">https://www.openssl.org</a>),
1271 is trying to reach the last couple-dozen people who have contributed code to
1272 OpenSSL. They are asking people to look at
1273 <a href="https://license.openssl.org/trying-to-find">https://license.openssl.org/trying-to-find</a>
1274 to see if they recognize any names. If so, contact
1275 <a href="mailto:license@openssl.org">license@openssl.org</a>
1276 with any information.</p>
1277
1278 <p>This marks one of the final steps in the project&rsquo;s work to change the license
1279 from its non-standard custom text, to the highly popular Apache License. This
1280 effort first started in the Fall of 2015, by requiring contributor agreements.
1281 Last March, the project made a major publicity effort, with large coverage in
1282 the industry. It also began to reach out and contact all contributors, as
1283 found by reviewing all changes made to the source. Over 600 people have
1284 already responded to emails or other attempts to contact them, and more than
1285 98% agreed with the change. The project removed the code of all those who
1286 disagreed with the change. In order to properly respect the desires of all
1287 original authors, the project continues to make strong efforts to find
1288 everyone.</p>
1289
1290 <p>Measured purely by simple metrics, the average contribution still outstanding
1291 is not large. There are a total of 59 commits without a response, out of a
1292 history of more than 32,300. On average, each person submitted a patch that
1293 modified 3-4 files, adding 100 lines and removing 23.</p>
1294
1295 <p>&ldquo;We&rsquo;re very pleased to be changing the license, and I am personally happy that
1296 OpenSSL has adopted the widely deployed Apache License,&rdquo; said Mark Cox, a
1297 founding member of the OpenSSL Management Committee. Cox is also a founder and
1298 former Board Member of the Apache Software Foundation.</p>
1299
1300 <p>The project hopes to conclude its two-year relicensing effort in time for the
1301 next release, which will include an implementation of TLS 1.3.</p>
1302
1303 <p>For more information, email
1304 <a href="osf-contact@openssl.org">osf-contact@openssl.org</a>.</p>
1305
1306 <p>-30-</p>
1307 ]]></content>
1308 </entry>
1309
1310 <entry>
1311 <title type="html"><![CDATA[Using TLS1.3 With OpenSSL]]></title>
1312 <link href="https://www.openssl.org/blog/blog/2018/02/08/tlsv1.3/"/>
1313 <updated>2018-02-08T12:00:00+01:00</updated>
1314 <id>https://www.openssl.org/blog/blog/2018/02/08/tlsv1.3</id>
1315 <content type="html"><![CDATA[<p>Note: This is an outdated version of this blog post. This information is now
1316 maintained in a wiki page. See
1317 <a href="https://wiki.openssl.org/index.php/TLS1.3">here</a> for the latest version.</p>
1318
1319 <p>The forthcoming OpenSSL 1.1.1 release will include support for TLSv1.3. The new
1320 release will be binary and API compatible with OpenSSL 1.1.0. In theory, if your
1321 application supports OpenSSL 1.1.0, then all you need to do to upgrade is to drop
1322 in the new version of OpenSSL when it becomes available and you will
1323 automatically start being able to use TLSv1.3. However there are some issues
1324 that application developers and deployers need to be aware of. In this blog post
1325 I am going to cover some of those things.</p>
1326
1327 <!-- more -->
1328
1329
1330 <h2>Differences with TLS1.2 and below</h2>
1331
1332 <p>TLSv1.3 is a major rewrite of the specification. There was some debate as to
1333 whether it should really be called TLSv2.0 - but TLSv1.3 it is. There are major
1334 changes and some things work very differently. A brief, incomplete, summary of
1335 some things that you are likely to notice follows:</p>
1336
1337 <ul>
1338 <li>There are new ciphersuites that only work in TLSv1.3. The old ciphersuites
1339 cannot be used for TLSv1.3 connections.</li>
1340 <li>The new ciphersuites are defined differently and do not specify the
1341 certificate type (e.g. RSA, DSA, ECDSA) or the key exchange mechanism (e.g.
1342 DHE or ECHDE). This has implications for ciphersuite configuration.</li>
1343 <li>Clients provide a &ldquo;key_share&rdquo; in the ClientHello. This has consequences for
1344 &ldquo;group&rdquo; configuration.</li>
1345 <li>Sessions are not established until after the main handshake has been
1346 completed. There may be a gap between the end of the handshake and the
1347 establishment of a session (or, in theory, a session may not be established at
1348 all). This could have impacts on session resumption code.</li>
1349 <li>Renegotiation is not possible in a TLSv1.3 connection</li>
1350 <li>More of the handshake is now encrypted.</li>
1351 <li>More types of messages can now have extensions (this has an impact on the
1352 custom extension APIs and Certificate Transparency)</li>
1353 <li>DSA certificates are no longer allowed in TLSv1.3 connections</li>
1354 </ul>
1355
1356
1357 <p>Note that at this stage only TLSv1.3 is supported. DTLSv1.3 is still in the
1358 early days of specification and there is no OpenSSL support for it at this time.</p>
1359
1360 <h2>Current status of the TLSv1.3 standard</h2>
1361
1362 <p>As of the time of writing TLSv1.3 is still in draft. Periodically a new version
1363 of the draft standard is published by the TLS Working Group. Implementations of
1364 the draft are required to identify the specific draft version that they are
1365 using. This means that implementations based on different draft versions do not
1366 interoperate with each other.</p>
1367
1368 <p>OpenSSL 1.1.1 will not be released until (at least) TLSv1.3 is finalised. In the
1369 meantime the OpenSSL git master branch contains our development TLSv1.3 code
1370 which can be used for testing purposes (i.e. it is not for production use). You
1371 can check which draft TLSv1.3 version is implemented in any particular OpenSSL
1372 checkout by examining the value of the TLS1_3_VERSION_DRAFT_TXT macro in the
1373 tls1.h header file. This macro will be removed when the final version of the
1374 standard is released.</p>
1375
1376 <p>TLSv1.3 is enabled by default in the latest development versions (there is no
1377 need to explicitly enable it). To disable it at compile time you must use the
1378 &ldquo;no-tls1_3&rdquo; option to &ldquo;config&rdquo; or &ldquo;Configure&rdquo;.</p>
1379
1380 <p>Currently OpenSSL has implemented the &ldquo;draft-23&rdquo; version of TLSv1.3. Other
1381 applications that support TLSv1.3 may still be using older draft versions. This
1382 is a common source of interoperability problems. If two peers supporting
1383 different TLSv1.3 draft versions attempt to communicate then they will fall back
1384 to TLSv1.2.</p>
1385
1386 <h2>Ciphersuites</h2>
1387
1388 <p>OpenSSL has implemented support for five TLSv1.3 ciphersuites as follows:</p>
1389
1390 <ul>
1391 <li><code>TLS13-AES-256-GCM-SHA384</code></li>
1392 <li><code>TLS13-CHACHA20-POLY1305-SHA256</code></li>
1393 <li><code>TLS13-AES-128-GCM-SHA256</code></li>
1394 <li><code>TLS13-AES-128-CCM-8-SHA256</code></li>
1395 <li><code>TLS13-AES-128-CCM-SHA256</code></li>
1396 </ul>
1397
1398
1399 <p>Of these the first three are in the <code>DEFAULT</code> ciphersuite group. This means that
1400 if you have no explicit ciphersuite configuration then you will automatically
1401 use those three and will be able to negotiate TLSv1.3.</p>
1402
1403 <p>All the TLSv1.3 ciphersuites also appear in the <code>HIGH</code> ciphersuite alias. The
1404 <code>CHACHA20</code>, <code>AES</code>, <code>AES128</code>, <code>AES256</code>, <code>AESGCM</code>, <code>AESCCM</code> and <code>AESCCM8</code>
1405 ciphersuite aliases include a subset of these ciphersuites as you would expect
1406 based on their names. Key exchange and authentication properties were part of
1407 the ciphersuite definition in TLSv1.2 and below. This is no longer the case in
1408 TLSv1.3 so ciphersuite aliases such as <code>ECDHE</code>, <code>ECDSA</code>, <code>RSA</code> and other similar
1409 aliases do not contain any TLSv1.3 ciphersuites.</p>
1410
1411 <p>If you explicitly configure your ciphersuites then care should be taken to
1412 ensure that you are not inadvertently excluding all TLSv1.3 compatible
1413 ciphersuites. If a client has TLSv1.3 enabled but no TLSv1.3 ciphersuites
1414 configured then it will immediately fail (even if the server does not support
1415 TLSv1.3) with an error message like this:</p>
1416
1417 <figure class='code'><div class="highlight"><table><tr><td class="gutter"><pre class="line-numbers"><span class='line-number'>1</span>
1418 </pre></td><td class='code'><pre><code class=''><span class='line'>140399519134144:error:141A90B5:SSL routines:ssl_cipher_list_to_bytes:no ciphers available:ssl/statem/statem_clnt.c:3715:No ciphers enabled for max supported SSL/TLS version</span></code></pre></td></tr></table></div></figure>
1419
1420
1421 <p>Similarly if a server has TLSv1.3 enabled but no TLSv1.3 ciphersuites it will
1422 also immediately fail, even if the client does not support TLSv1.3, with an
1423 error message like this:</p>
1424
1425 <figure class='code'><div class="highlight"><table><tr><td class="gutter"><pre class="line-numbers"><span class='line-number'>1</span>
1426 </pre></td><td class='code'><pre><code class=''><span class='line'>140640328024512:error:141FC0B5:SSL routines:tls_setup_handshake:no ciphers available:ssl/statem/statem_lib.c:120:No ciphers enabled for max supported SSL/TLS version</span></code></pre></td></tr></table></div></figure>
1427
1428
1429 <p>For example, setting a ciphersuite selection string of
1430 <code>ECDHE:!COMPLEMENTOFDEFAULT</code> will work in OpenSSL 1.1.0 and will only select
1431 those ciphersuites that are in DEFAULT and also use ECDHE for key exchange.
1432 However no TLSv1.3 ciphersuites are in the ECDHE group so this ciphersuite
1433 configuration will fail in OpenSSL 1.1.1 if TLSv1.3 is enabled.</p>
1434
1435 <p>You may want to explicitly list the TLSv1.3 ciphersuites you want to use to
1436 avoid problems. For example:</p>
1437
1438 <figure class='code'><div class="highlight"><table><tr><td class="gutter"><pre class="line-numbers"><span class='line-number'>1</span>
1439 </pre></td><td class='code'><pre><code class=''><span class='line'>"TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384:ECDHE:!COMPLEMENTOFDEFAULT"</span></code></pre></td></tr></table></div></figure>
1440
1441
1442 <p>You can test which ciphersuites are included in a given ciphersuite selection
1443 string using the <code>openssl ciphers -s -v</code> command:</p>
1444
1445 <figure class='code'><div class="highlight"><table><tr><td class="gutter"><pre class="line-numbers"><span class='line-number'>1</span>
1446 </pre></td><td class='code'><pre><code class=''><span class='line'>$ openssl ciphers -s -v "ECDHE:!COMPLEMENTOFDEFAULT"</span></code></pre></td></tr></table></div></figure>
1447
1448
1449 <p>Ensure that at least one ciphersuite supports TLSv1.3</p>
1450
1451 <h2>Groups</h2>
1452
1453 <p>In TLSv1.3 the client selects a &ldquo;group&rdquo; that it will use for key exchange.
1454 At the time of writing, OpenSSL only supports ECDHE groups for this. The client
1455 then sends &ldquo;key_share&rdquo; information to the server for its selected group in the
1456 ClientHello.</p>
1457
1458 <p>The list of supported groups is configurable. It is possible for a client to
1459 select a group that the server does not support. In this case the server
1460 requests that the client sends a new key_share that it does support. While this
1461 means a connection will still be established (assuming a mutually supported
1462 group exists), it does introduce an extra server round trip - so this has
1463 implications for performance. In the ideal scenario the client will select a
1464 group that the server supports in the first instance.</p>
1465
1466 <p>In practice most clients will use X25519 or P-256 for their initial key_share.
1467 For maximum performance it is recommended that servers are configured to support
1468 at least those two groups and clients use one of those two for its initial
1469 key_share. This is the default case (OpenSSL clients will use X25519).</p>
1470
1471 <p>The group configuration also controls the allowed groups in TLSv1.2 and below.
1472 If applications have previously configured their groups in OpenSSL 1.1.0 then
1473 you should review that configuration to ensure that it still makes sense for
1474 TLSv1.3. The first named (i.e. most preferred group) will be the one used by an
1475 OpenSSL client in its intial key_share.</p>
1476
1477 <p>Applications can configure the group list by using <code>SSL_CTX_set1_groups()</code> or a
1478 similar function (see
1479 <a href="https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set1_groups.html">here</a> for
1480 further details). Alternatively, if applications use <code>SSL_CONF</code> style
1481 configuration files then this can be configured using the <code>Groups</code> or <code>Curves</code>
1482 command (see
1483 <a href="https://www.openssl.org/docs/manmaster/man3/SSL_CONF_cmd.html#SUPPORTED-CONFIGURATION-FILE-COMMANDS">here</a>).</p>
1484
1485 <h2>Sessions</h2>
1486
1487 <p>In TLSv1.2 and below a session is established as part of the handshake. This
1488 session can then be used in a subsequent connection to achieve an abbreviated
1489 handshake. Applications might typically obtain a handle on the session after a
1490 handshake has completed using the <code>SSL_get1_session()</code> function (or similar). See
1491 <a href="https://www.openssl.org/docs/manmaster/man3/SSL_get1_session.html">here</a> for
1492 further details.</p>
1493
1494 <p>In TLSv1.3 sessions are not established until after the main handshake has
1495 completed. The server sends a separate post-handshake message to the client
1496 containing the session details. Typically this will happen soon after the
1497 handshake has completed, but it could be sometime later (or not at all).</p>
1498
1499 <p>The specification recommends that applications only use a session once (although
1500 this is not enforced). For this reason some servers send multiple session
1501 messages to a client. To enforce the &ldquo;use once&rdquo; recommendation applications could
1502 use <code>SSL_CTX_remove_session()</code> to mark a session as non-resumable (and remove it
1503 from the cache) once it has been used.</p>
1504
1505 <p>The old <code>SSL_get1_session()</code> and similar APIs may not operate as expected for
1506 client applications written for TLSv1.2 and below. Specifically if a client
1507 application calls <code>SSL_get1_session()</code> before the server message containing
1508 session details has been received then an <code>SSL_SESSION</code> object will still be
1509 returned, but any attempt to resume with it will not succeed and a full
1510 handshake will occur instead. In the case where multiple sessions have been sent
1511 by the server then only the last session will be returned by
1512 <code>SSL_get1_session()</code>.</p>
1513
1514 <p>Client application developers should consider using the
1515 <code>SSL_CTX_sess_set_new_cb()</code> API instead (see
1516 <a href="https://www.openssl.org/docs/manmaster/man3/SSL_CTX_sess_set_new_cb.html">here</a>).
1517 This provides a callback mechanism which gets invoked every time a new session
1518 is established. This can get invoked multiple times for a single connection if a
1519 server sends multiple session messages.</p>
1520
1521 <p>Note that <code>SSL_CTX_sess_set_new_cb()</code> was also available in OpenSSL 1.1.0.
1522 Applications that already used that API will still work, but they may find that
1523 the callback is invoked at unexpected times, i.e. post-handshake.</p>
1524
1525 <p>An OpenSSL server will immediately attempt to send session details to a client
1526 after the main handshake has completed. To server applications this
1527 post-handshake stage will appear to be part of the main handshake, so calls to
1528 <code>SSL_get1_session()</code> should continue to work as before.</p>
1529
1530 <h2>Custom Extensions and Certificate Transparency</h2>
1531
1532 <p>In TLSv1.2 and below the initial ClientHello and ServerHello messages can
1533 contain &ldquo;extensions&rdquo;. This allows the base specifications to be extended with
1534 additional features and capabilities that may not be applicable in all scenarios
1535 or could not be foreseen at the time that the base specifications were written.
1536 OpenSSL provides support for a number of &ldquo;built-in&rdquo; extensions.</p>
1537
1538 <p>Additionally the custom extensions API provides some basic capabilities for
1539 application developers to add support for new extensions that are not built-in
1540 to OpenSSL.</p>
1541
1542 <p>Built on top of the custom extensions API is the &ldquo;serverinfo&rdquo; API. This provides
1543 an even more basic interface that can be configured at run time. One use case
1544 for this is Certificate Transparency. OpenSSL provides built-in support for the
1545 client side of Certificate Transparency but there is no built-in server side
1546 support. However this can easily be achieved using &ldquo;serverinfo&rdquo; files. A
1547 serverinfo file containing the Certificate Transparency information can be
1548 configured within OpenSSL and it will then be sent back to the client as
1549 appropriate.</p>
1550
1551 <p>In TLSv1.3 the use of extensions is expanded significantly and there are many
1552 more messages that can include them. Additionally some extensions that were
1553 applicable to TLSv1.2 and below are no longer applicable in TLSv1.3 and some
1554 extensions are moved from the ServerHello message to the EncryptedExtensions
1555 message. The old custom extensions API does not have the ability to specify
1556 which messages the extensions should be associated with. For that reason a new
1557 custom extensions API was required.</p>
1558
1559 <p>The old API will still work, but the custom extensions will only be added where
1560 TLSv1.2 or below is negotiated. To add custom extensions that work for all TLS
1561 versions application developers will need to update their applications to the
1562 new API (see
1563 <a href="https://www.openssl.org/docs/manmaster/man3/SSL_CTX_add_custom_ext.html">here</a>
1564 for details).</p>
1565
1566 <p>The &ldquo;serverinfo&rdquo; data format has also been updated to include additional
1567 information about which messages the extensions are relevant to. Applications
1568 using &ldquo;serverinfo&rdquo; files may need to update to the &ldquo;version 2&rdquo; file format to be
1569 able to operate in TLSv1.3 (see
1570 <a href="https://www.openssl.org/docs/manmaster/man3/SSL_CTX_use_serverinfo.html">here</a>
1571 and <a href="https://www.openssl.org/docs/manmaster/man3/SSL_CTX_use_serverinfo_file.html">here</a>
1572 for details).</p>
1573
1574 <h2>Renegotiation</h2>
1575
1576 <p>TLSv1.3 does not have renegotiation so calls to <code>SSL_renegotiate()</code> or
1577 <code>SSL_renegotiate_abbreviated()</code> will immediately fail if invoked on a connection
1578 that has negotiated TLSv1.3.</p>
1579
1580 <p>A common use case for renegotiation is to update the connection keys. The
1581 function <code>SSL_key_update()</code> can be used for this purpose in TLSv1.3 (see
1582 <a href="https://www.openssl.org/docs/manmaster/man3/SSL_key_update.html">here</a> for
1583 further details).</p>
1584
1585 <p>Another use case is to request a certificate from the client. This can be
1586 achieved by using the <code>SSL_verify_client_post_handshake()</code> function in TLSv1.3
1587 (see <a href="https://www.openssl.org/docs/manmaster/man3/SSL_verify_client_post_handshake.html">here</a>
1588 for further details).</p>
1589
1590 <h2>DSA certificates</h2>
1591
1592 <p>DSA certificates are no longer allowed in TLSv1.3. If your server application is
1593 using a DSA certificate then TLSv1.3 connections will fail with an error message
1594 similar to the following:</p>
1595
1596 <figure class='code'><div class="highlight"><table><tr><td class="gutter"><pre class="line-numbers"><span class='line-number'>1</span>
1597 </pre></td><td class='code'><pre><code class=''><span class='line'>140348850206144:error:14201076:SSL routines:tls_choose_sigalg:no suitable signature algorithm:ssl/t1_lib.c:2308:</span></code></pre></td></tr></table></div></figure>
1598
1599
1600 <p>Please use an ECDSA or RSA certificate instead.</p>
1601
1602 <h2>Middlebox Compatibility Mode</h2>
1603
1604 <p>During development of the TLSv1.3 standard it became apparent that in some cases,
1605 even if a client and server both support TLSv1.3, connections could sometimes
1606 still fail. This is because middleboxes on the network between the two peers
1607 do not understand the new protocol and prevent the connection from taking place.
1608 In order to work around this problem the TLSv1.3 specification introduced a
1609 &ldquo;middlebox compatibility&rdquo; mode. This made a few optional changes to the protocol
1610 to make it appear more like TLSv1.2 so that middleboxes would let it through.
1611 Largely these changes are superficial in nature but do include sending some
1612 small but unneccessary messages. OpenSSL has middlebox compatibility mode on by
1613 default, so most users should not need to worry about this. However applications
1614 may choose to switch it off by calling the function <code>SSL_CTX_clear_options()</code>
1615 and passing <code>SSL_OP_ENABLE_MIDDLEBOX_COMPAT</code> as an argument (see
1616 <a href="https://www.openssl.org/docs/manmaster/man3/SSL_CTX_clear_options.html">here</a>
1617 for further details).</p>
1618
1619 <p>If the remote peer is not using middlebox compatibility mode and there are
1620 problematic middleboxes on the network path then this could cause spurious
1621 connection failures.</p>
1622
1623 <h2>Conclusion</h2>
1624
1625 <p>TLSv1.3 represents a significant step forward and has some exciting new features
1626 but there are some hazards for the unwary when upgrading. Mostly these issues
1627 have relatively straight forward solutions. Application developers should review
1628 their code and consider whether anything should be updated in order to work more
1629 effectively with TLSv1.3. Similarly application deployers should review their
1630 configuration.</p>
1631 ]]></content>
1632 </entry>
1633
1634 </feed>
Response: application/gopher-menu
Original URLgopher://codemadness.org/1/git/sfeed_tests/file/input/sfe...
Content-Typeapplication/gopher-menu; charset=utf-8