自从2014年4月7日Openssl的心脏出血Heartbleed漏洞被曝出现后引起了广大开源社区的重视，有实力有需求的厂商和开源组织开始重新审视Openssl加密库的安全问题，因此先后出现了像boringssl,libressl,quictls等新的版本的openssl库。呈现出百花齐放的来源事态。
Openssl的心脏出血Heartbleed是一个出现在加密程序库OpenSSL的安全漏洞，该程序库广泛用于实现互联网的传输层安全（TLS）协议。它于2012年被引入了软件中，2014年4月首次向公众披露。只要使用的是存在缺陷的OpenSSL实例，无论是服务器还是客户端，都可能因此而受到攻击。此问题的原因是在实现TLS的心跳扩展时没有对输入进行适当验证（缺少边界检查），因此漏洞的名称来源于“心跳”（heartbeat）。该程序错误属于缓冲区过滤，即可以读取的数据比应该允许读取的还多。HeartBleed主要存在与OpenSSL的1.0.1版本到1.0.1f版本。利用该漏洞，攻击者可以远程读取服务器内存中64K的数据，获取内存中的敏感信息。
我们这里谈谈这三个主流的取代openssl的加密库:
Boringssl
Boringssl是谷歌主导的一个openssl分支，目的为满足gooogle自己的开发需求而建立。虽然BoringSSL是一个开源项目，但它并不适合一般 使用，就像 OpenSSL 一样，谷歌不建议第三方依赖它。谷歌不提供对第三方的API及ABI和稳定性保证。话虽如此，谷歌的意思是不要过分依赖第三方的版本，而是根据自己需求去构建自己的副本。谷歌的Boringssl的正是因为谷歌日益增加的内部需求而构建来的。但是其实谷歌自身的产品包括Chrome/Chromium、Android都使用了Boringssl库。
Boringssl具备谷歌很多创新和紧扣技术发展的新的更新。印象中它好像是最早引入Quic库的。因此个人建议是:该用则用，背靠大树好乘凉！
Libressl
LibreSSL是OpenSSL加密软件库的一个分支，为一个安全套接层（SSL）和传输层安全（TLS）协议的开源实现。在OpenSSL爆出心脏出血安全漏洞之后，一些OpenBSD开发者于2014年4月创立了LibreSSL，目标是重构OpenSSL的代码，以提供一个更安全的替代品。LibreSSL复刻自OpenSSL库的1.0.1g分支，它将遵循其他OpenBSD项目所使用的安全指导原则。
从以上官方的介绍我们可以看到libressl是从安全角度重构的一个ssl库。LibreSSL 是由 OpenBSD 项目开发的 OpenSSL 1.0.1g 的一个分支。目标是对代码库进行现代化改造， 提高安全性，并应用 OpenBSD 的最佳实践开发流程。
LibreSSL 提供了大部分 OpenSSL 1.1 API。OpenSSL 3 API 当前没有 支持。项目之间存在不兼容性，并且由于 两者都以不同的目标和优先事项发展。重要的不兼容性将 如果可能的话，只要它们对 LibreSSL 的不太有害，就可以解决 简单、安全和理智的目标。我们不会添加新功能、密码和 没有充分理由的 API，并要求新代码干净且高质量。
Libressl不保证兼容openssl的API和ABI。当然毕竟都复刻修改的分支，陈旧的openssl确实也需要持续进步和发展了。
Libressl提供相当高的稳定性和移植兼容性虽然主要是在 OpenBSD 上开发并利用 API 的， LibreSSL 可移植项目试图为 其他操作系统，并协助改进操作系统原生实现 在可能的情况下。
在撰写本文时，已知 LibreSSL 正在构建和工作：
Linux（推荐内核 3.17 或更高版本）
FreeBSD （在 9.2 及更高版本中测试）
NetBSD（推荐使用 7.0 或更高版本）
惠普-UX （11i）
Solaris 11 及更高版本
Mac OS X（在 10.8 及更高版本上测试）
AIX（5.3 及更高版本）
LibreSSL 还支持以下 Windows 环境：
Microsoft Windows（Windows 7 / Windows Server 2008R2 或更高版本，x86 和 x64）
Wine（32 位和 64 位）
Mingw-w64、Cygwin 和 Visual Studio。
个人建议:系统集成级别的安全性和开发流程，稳定的开发流程。可以放心的使用，但是在一些特别前沿的开发可能会略晚。毕竟谷歌有钱有人嘛！
QuicTLS
QuicTLS是另一个Openssl分支，此分支添加了 QUIC 实现可用于连接的 API 握手。引用 IETF 工作组章程，QUIC 是一个“基于 UDP、 流多路复用，加密传输协议。这里的 API 由 Microsoft 的 MsQuic 和 Google 的 Chromium QUIC 提供。因此我们可以看出QuicTLS单纯就是openssl+quic API支持。因此我们认为应该只在需要Quic的时候使用，其他时候官方也建议直接使用Openssl.个人建议:需要保持相对纯净的QUIC需求的可以使用。这家背是 Akamai 和 Microsoft。
总结：
三者都可以使用，需要一些新功能和看好谷歌的直接选择Broingssl,需要系统级稳定性的选择Libressl。
参考:
https://github.com/google/boringssl
