<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>OpenSSL on Locus Solus | Nagi's Blog</title><link>https://x-nagi.com/tags/openssl.html</link><description>Recent content in OpenSSL on Locus Solus | Nagi's Blog</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Fri, 21 Dec 2018 18:46:06 +0800</lastBuildDate><atom:link href="https://x-nagi.com/tags/openssl/index.xml" rel="self" type="application/rss+xml"/><item><title>Building and Installing OpenSSL on Windows</title><link>https://x-nagi.com/post/windows-openssl.html</link><pubDate>Fri, 21 Dec 2018 18:46:06 +0800</pubDate><guid>https://x-nagi.com/post/windows-openssl.html</guid><description>&lt;p&gt;I recently needed OpenSSL on Windows for a challenge. I had always built it through MSYS/MinGW, which produces the static libraries &lt;code&gt;libcrypto.a&lt;/code&gt; and &lt;code&gt;libssl.a&lt;/code&gt; (as well as DLLs, although I generally prefer static linking). Programs compiled with GCC can use them with &lt;code&gt;-lssl -lcrypto&lt;/code&gt;. These libraries only work with MinGW, however, and cannot be used by Visual Studio; MinGW&amp;rsquo;s Win32 API support is hardly praiseworthy either. I therefore investigated how to build OpenSSL with Visual C++.&lt;/p&gt;</description></item><item><title>Configuring TLS 1.3 Cipher Suites in Nginx with OpenSSL</title><link>https://x-nagi.com/post/nginx-tls1-3-patch.html</link><pubDate>Fri, 30 Nov 2018 10:27:13 +0800</pubDate><guid>https://x-nagi.com/post/nginx-tls1-3-patch.html</guid><description>&lt;p&gt;The final TLS 1.3 specification, RFC 8446, was published in August 2018. Out of curiosity, I installed OpenSSL 1.1.1 to enable TLS 1.3 support. Recently, however, I noticed that Nginx always selected &lt;code&gt;TLS_AES_256_GCM_SHA384&lt;/code&gt; under TLS 1.3, regardless of the cipher-suite order in &lt;code&gt;ssl_ciphers&lt;/code&gt;; even explicitly requesting AES-128 made no difference. This was not a serious problem, but to a would-be perfectionist it made the configuration feel incomplete.&lt;/p&gt;</description></item><item><title>ZJUWLAN auto connect</title><link>https://x-nagi.com/post/zjuwlan-autoconnect.html</link><pubDate>Sat, 10 Nov 2018 10:36:52 +0800</pubDate><guid>https://x-nagi.com/post/zjuwlan-autoconnect.html</guid><description>&lt;div class="admonition success"&gt;&lt;p class="admonition-title"&gt;success&lt;/p&gt;&#10;&lt;p&gt;ZJU finally deployed WPA2 and 802.1X, so browser-based authentication is no longer necessary.&lt;/p&gt;&#10;&lt;/div&gt;&#10;&lt;p&gt;Recently, ZJUWLAN kept disconnecting for no apparent reason. The campus network required opening a browser to log in and then displayed a small “login successful” window—which i3wm tiled like an ordinary window. This was unbearable for a would-be perfectionist, so I wondered whether a script could perform the login directly and opened Chrome&amp;rsquo;s developer tools to investigate.&lt;/p&gt;</description></item></channel></rss>