Add post - JetBrains Writerside EAP Expiration Bypass

_layouts/default.html

@@ -74,12 +74,12 @@
         <span class="site-footer-owner">
           <a href="https://chylex.com">My Website</a>
           &nbsp;&middot;&nbsp;
-          <a href="https://twitter.com/chylexmc">Twitter</a>
+          <a href="https://chylex.bsky.social/">Bluesky</a>
+          &nbsp;&middot;&nbsp;
+          <a href="https://mastodon.chylex.com/@chylex">Mastodon</a>
           &nbsp;&middot;&nbsp;
           <a href="https://github.com/chylex">GitHub</a>
           &nbsp;&middot;&nbsp;
-          <a href="https://patreon.com/chylex">Patreon</a>
-          &nbsp;&middot;&nbsp;
           <a href="https://ko-fi.com/chylex">Ko-fi</a>
           &nbsp;&middot;&nbsp;
           <a href="{{ '/feed.xml' | relative_url }}">RSS</a>

_posts/2023-04-14-ultimate-guide-to-mysql-ssl.md

@@ -1,39 +1,43 @@
 ---
 title: "The Ultimate Guide to Securing MySQL / MariaDB + PHP with SSL"
 subtitle: "%pub"
-date: 2023-04-10
+date: 2023-04-14
-#commentid: 1
+commentid: 4
 ---
 
 By default, all communication between a MySQL or MariaDB server and its clients is unencrypted. That's fine if both the database server and client are on the same machine, or connected by a network you fully control, but as soon as anything touches the internet — or even an internal data center network the [NSA may have secretly tapped into](https://www.washingtonpost.com/world/national-security/nsa-infiltrates-links-to-yahoo-google-data-centers-worldwide-snowden-documents-say/2013/10/30/e51d661e-4166-11e3-8b74-d89d714ca4dd_story.html) — all bets are off, and you need SSL to ensure that the communication cannot be spied on or tampered with. This post will guide you through the entire process in an abundance of detail.
 
-To be clear, I'm no expert on cryptography, and I certainly wasn't expecting to be writing a whole tutorial on setting up SSL for MySQL / MariaDB + PHP within hours of getting mine to work, but while researching this I found so much outdated or just straight up bad information — including issues in the official MySQL and MariaDB documentation — that I took time to dig deep into every step of the process. While reading this guide, you should never feel you're being told to run a command or change some code without an explanation that justifies the decision.
+To be clear, I'm no expert on cryptography, and I certainly wasn't expecting to be writing a whole tutorial on setting up SSL for MySQL / MariaDB + PHP within hours of getting mine to work, but while researching this I found so much outdated or just straight up bad information that I took time to dig deep into every step of the process. While reading this guide, you should never feel you're being told to run a command or change some code without an explanation that justifies it.
 
 # 0. Prerequisites
 
-I will assume that you have a MySQL or MariaDB server, access to its configuration files, and PHP scripts that connect to it. I will also assume you are always using the most recent version of all software involved. Unfortunately, I cannot predict any changes that invalidate something in this post, so if you run into any issues in the future, please let me know.
+I will assume that you have a MySQL or MariaDB server, access to its configuration files, and PHP scripts that connect to it. I will also assume you are always using the most recent version of all software involved. I cannot predict any future software updates that invalidate something in this post, so if you run into issues, please let me know in the comments.
+
+Many parts of this guide are based on the official documentation of [MySQL](https://dev.mysql.com/doc/refman/8.0/en/creating-ssl-files-using-openssl.html) and [MariaDB](https://mariadb.com/kb/en/certificate-creation-with-openssl/).
 
 Now, get yourself a Linux machine with `openssl` and let's get started.
 
 # 1. Generating Certificates
 
-This section is largely based on the official documentation of [MySQL](https://dev.mysql.com/doc/refman/8.0/en/creating-ssl-files-using-openssl.html) and [MariaDB](https://mariadb.com/kb/en/certificate-creation-with-openssl/).
+Let's establish some terminology. SSL uses "asymmetric cryptography" to establish a secure communication channel. Every *entity* needs a key pair — a private key, and a public key — that each serve two functions:
+1. The public key is used to encrypt messages. Only the private key can decrypt those messages.
+2. The private key is used to sign messages. The public key can verify those signatures.
 
-Let's establish some basic terminology. We will be using "asymmetric cryptography", in which every entity needs a key pair — a private key, and a public key. The private key is used to encrypt or sign messages, and the public key is used on the receiving end to decrypt messages and verify signatures. For SSL, when we generate public keys, they will be immediately turned into public key *certificates* which contain some additional information besides just the public key itself.
+The public key will be embedded in a *public key certificate*, which contains additional information about the identity of its owner. The private key and public key certificate will be generated using ~~magic~~ a bunch of math, and stored in separate files.
 
-For every entity, we will end up with a file containing the *private key*, and a file containing the *public key certificate*. From now on, I will simplify the terminology and use "key" to mean the private key, and "certificate" or "cert" to mean the public key certificate. Later we will see this simplified terminology used in both MySQL / MariaDB configuration, and in the PHP code for configuring the database connection.
+From now on, I will simplify the terminology and use "key" to mean the private key, and "certificate" or "cert" to mean the public key certificate. Later we will see this simplified terminology used in both MySQL / MariaDB configuration, and in the PHP code for configuring the database connection.
+
+Before generating any keys of certificates, we must pick an *algorithm*. Both official documentations use 2048-bit RSA. As far as RSA goes, 2048 bits is the absolute minimum nowadays. It might be a good idea to increase the key size to 3072, 4096, or even more bits for better resilience against progress in (non-quantum) computing performance, but that comes at the expense of spending more time establishing every connection. The world seems to be moving away from RSA and towards elliptic curves, which have several benefits including much smaller keys, so we might as well use the current best thing. Based on recommendations from [Trail of Bits](https://blog.trailofbits.com/2019/07/08/fuck-rsa/) and [Soatok](https://soatok.blog/2022/05/19/guidance-for-choosing-an-elliptic-curve-signature-algorithm-in-2022/), I will use Ed25519.
 
 ## Certificate Authority
 
-First, we roleplay as a "Certificate Authority" (CA), the first entity on our list. If you hate fun, you can take inspiration from modern "Free-to-play" games and simply pay a *real* Certificate Authority to skip this part.
+First, we roleplay as a "Certificate Authority" (CA), the first *entity* for which we will be generating a key and a certificate. If you hate fun, you can take inspiration from modern "Free-to-play" games and simply pay a *real* Certificate Authority to skip this part.
 
-We will generate a "CA key" and a "CA certificate" (which, as a reminder, is what I'm calling the private key and public key certificate respectively) out of ~~magic~~ a bunch of math. The purpose of the CA is to *sign* other certificates. We will distribute the CA certificate to every computer that either hosts the database server or connects to it. When these *other certificates* are later sent and downloaded over an untrusted network, our trusty CA certificate will verify their signature. If the signature is valid, because we know we can trust the CA, we can also trust these *other certificates*. If the signature is not valid, it means the *other certificate* has been forged or otherwise corrupted, and it is impossible to establish secure and trusted communication to the database server.
+The purpose of the CA is to *sign other certificates*, using the (private) CA key. We will then distribute the (public) CA certificate to every computer that either hosts the database server or connects to it. When these *other certificates* are sent and received over an untrusted network, the CA certificate will verify their signature. If the signature is valid, we know that it must have been signed by our CA — which we trust — so the *other certificate* can also be trusted. If the signature is not valid, it means the *other certificate* has been forged or otherwise corrupted, and it is impossible to establish secure and trusted communication with the database server.
-
-Before generating anything, we must decide which *algorithm* to use. Both official documentations use 2048-bit RSA. As far as RSA goes, 2048 bits is the absolute minimum nowadays. Increasing the key size to 3072, 4096, or even more bits, increases resilience against progress in (non-quantum) computing performance, while also increasing how long it takes to establish every connection. The world seems to be moving away from RSA and towards elliptic curves anyway, so we might as well try to use the current best thing, and hopefully not worry about it for a while. Based on the recommendations from [Trail of Bits](https://blog.trailofbits.com/2019/07/08/fuck-rsa/) and [Soatok](https://soatok.blog/2022/05/19/guidance-for-choosing-an-elliptic-curve-signature-algorithm-in-2022/), I will use Ed25519.
 
 It's terminal time. Navigate to a folder where you want your certificates.
 
-This snippet generates a private key for our Certificate Authority, and saves it to a `ca_key.pem` file.
+This snippet generates a private key using the Ed25519 algorithm, and saves it to a `ca_key.pem` file.
 ```bash
 openssl genpkey -algorithm ed25519 > ca_key.pem
 ```
@@ -45,11 +49,11 @@ openssl req -new -x509 -nodes -days 365000 -subj "/C=US/O=organization/OU=organi
 
 Let's go through what this means:
 1. `openssl req -new` means we are creating a new "certificate signing request".
-2. `-x509` means that the "certificate signing request" will be immediately turned into a self-signed certificate in the X.509 format.
+2. `-x509` means that the "certificate signing request" will be immediately turned into a self-signed certificate in the X.509 format. Otherwise, it would be saved as a file, and we'd need another command to sign it.
 3. `-nodes` ("no DES") disables encryption of the certificate. If encryption is enabled, you will be asked for a passphrase, and then must provide this passphrase whenever you want to use the certificate. Encrypting certificates provides more security at the expense of convenience, but I cannot find any evidence that either MySQL or MariaDB supports encrypted certificates, so we don't have a choice here.
-4. `-days 365000` sets the certificate expiry time to roughly 1000 years, which is fairly optimistic considering how humanity is going. You can use shorter expiry times, but you need to think about renewal and this s\*\*t is already complicated enough. It can be a useful feature in case your private key leaks and you never realize, however recommended expiry times are often in the realm of months or years which is plenty of time for an attacker to cause harm, and if you do realize that your private key leaked, you can simply regenerate all keys and certificates and easily swap them out since you have full control over your PHP scripts.
+4. `-days 365000` sets the expiry time to roughly 1000 years, which is fairly optimistic considering how humanity is going. You can use shorter expiry times, but you need to think about renewal and this s\*\*t is already complicated enough. Shorter expiry times can help if your private key leaks and you never realize, but recommended expiry times are often in the realm of months or years, which is plenty of time for an attacker to cause harm. Moreover, if you do realize your private key leaked, you can regenerate all keys and certificates and swap them out, which should be relatively easy since they only reside on computers you fully control.
 5. `-subj ...` is the spicy stuff. It is a slash-delimited sequence of key-value pairs of various fields embedded in the certificate. Most are optional, but useful for documenting where the certificate came from. There are standards for these, but since you are the only one using these certificates, for the unimportant fields just type in whatever doesn't crash `openssl`.
-   - `C` is a two-letter country code. The smaller and less known your country is, the more I recommend setting it.
+   - `C` is a two-letter country code. The lesser-known your country is, the more I recommend setting it.
    - `O` is the organization name. Despite my lack of organization, I set it to my nickname.
    - `OU` is the organizational unit. I set it to `mysql` to describe where these certificates will be used.
    - `CN` is the common name, which is supposed to identify the certificate's origin. For the CA, it's not really important. For example, you can just set it to your username. I set it to the domain name of the server which stores the CA key and certificate, but if you are planning to do that, you must use a different domain name than the one used for the database server — we will come back to that later.
@@ -58,44 +62,54 @@ Let's go through what this means:
 6. `-key` is the file name of the private key.
 7. `-out` is the file name to create for the certificate.
 
-We end up with a private key `ca_key.pem` that we need to keep secret, and a public key certificate `ca_cert.pem` that needs to be copied to the database server and to every client that wants to use SSL to connect to the database server.
+We end up with a private key `ca_key.pem` that we need to keep secret, and a public key certificate `ca_cert.pem` that needs to be copied to the database server and to every client that connects to the database server.
 
 ## Server Certificates
 
-Let's now do the same thing, but this time generate a key and a certificate for the database server. When a client connects to the database server, the server will automatically send its certificate to the client. After the client verifies the server certificate against the CA certificate, it will use the server certificate to encrypt some secret information, which only the server can decrypt. This secret information is used to establish a new, symmetrically encrypted communication channel. You might be asking why we are establishing a new encrypted channel when we already have one, and there are two reasons:
+Let's now generate a key and a certificate for the database server. When a client connects to the database server, the server will automatically send its certificate to the client. After the client verifies that the server certificate was signed by the CA certificate, it will use the server certificate to encrypt some secret information which only the server can decrypt. This secret information is used to establish a new, symmetrically encrypted communication channel. You might be asking why we are establishing a new encrypted channel when we already have one, and there are two reasons:
 1. The client may not have its own key and certificate, in which case the server has no way to encrypt messages in a way that only the client can decrypt.
 2. Asymmetric encryption needs a lot more computing resources than symmetric encryption.
 
-Now that we've finished our educational side-quest, let's generate a key and a *certificate request*.
+Now that we've finished our educational side-quest, let's generate a key and a *certificate signing request*.
 ```bash
 openssl req -newkey ed25519 -nodes -subj "/C=US/O=organization/OU=organizational_unit/CN=server_hostname" -keyout "server_key.pem" -out "server_req.pem"
 ```
 
-Most of these arguments are the same as before. The differences are:
+Most of these are the same as before. The differences are:
 1. `-newkey` is like `-new`, but it also generates a private key at the same time as the certificate signing request. Note that this time there is no `-x509`, so we do actually create a certificate signing request that we will sign later.
 2. `ed25519` uses the Ed25519 algorithm for the private key.
 3. `-subj ...` is largely the same, **but!**
-   - `CN` must be the hostname of the database server you use in your PHP script! This will be checked, and if it does not match, the connection will fail with an error: ``Peer certificate CN=`...' did not match expected CN=`...'``. It must also be different from the `CN` field you used for the Certificate Authority, otherwise the connection is rejected by database servers with OpenSSL with this error: `OpenSSL Error messages: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed`. Inconveniently, MariaDB documentation does not mention this at all, and MySQL documentation does but too early — before you learn what any of this even means.
+   - `CN` must be the hostname of the database server you use in your PHP script! If it doesn't match, the connection will fail with an error:
+     ```
+     Peer certificate CN=`...' did not match expected CN=`...'
+     ```
+     It must also be different from the `CN` field you used for the Certificate Authority, otherwise database servers with OpenSSL will reject the connection with this error:
+     ```
+     OpenSSL Error messages: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
+     ```
+     Inconveniently, MariaDB documentation does not mention this at all, and MySQL documentation does but too early — before you learn what any of this even means.
 4. `-keyout` is the file name to create for the private key.
 
 At this point, both official documentations say to run a command to "remove the passphrase" from the private key. If you remember from earlier, the `-nodes` argument — which both documentations use — already disables passphrase-based encryption, so there is no point removing something that doesn't exist.
 
-Now, we turn the certificate signing request into an actual certificate by using our Certificate Authority to sign it:
+Let's turn the certificate signing request into an actual certificate by using our Certificate Authority to sign it:
 ```bash
 openssl x509 -req -days 365000 -set_serial 1 -CA ca_cert.pem -CAkey ca_key.pem -in "server_req.pem" -out "server_cert.pem" -extfile /etc/ssl/openssl.cnf -extensions usr_cert
 ```
 
 New thingies to learn!
 1. `openssl x509` begins a command related to X.509 certificates. You may be wondering — we already did a bunch of things with X.509 certificates, why have we not seen this command yet? Anyway,
-2. `-req` means we are turning a certificate request into a certificate. Very different from `req`.
+2. `-req` means we are turning a certificate signing request into a certificate. Very different from `req`.
-3. `-set_serial` specifies a serial number for the certificate. This number should be **unique for your CA**. This server certificate uses serial number `1`, the next certificate I make with the same CA will use serial number `2`, etc.
+3. `-set_serial` specifies a serial number for the certificate. This number should be **unique for our CA**. This server certificate uses serial number `1`, the next certificate we make with the same CA will use serial number `2`, etc.
-4. `-CA` is the file name of the CA certificate.
+4. `-CA` is a path to the CA certificate.
-5. `-CAkey` is the file name of the CA (private) key, and also the fourth f\*\*\*ing way to capitalize arguments in the `openssl` command.
+5. `-CAkey` is a path to the CA key, and also the fourth f\*\*\*ing way to capitalize arguments in the `openssl` command.
 6. `-in` is the file name of the certificate signing request.
-7. `-extfile` is the path to a file containing X.509 v3 extensions. We are using the default OpenSSL configuration file.
+7. `-extfile` is a path to a file containing X.509 v3 extensions. We use the default OpenSSL configuration file.
-8. `-extensions usr_cert` then uses a particular set of X.509 v3 extensions that the default configuration file intends to be used when a CA signs a certificate request.
+8. `-extensions usr_cert` then uses a particular set of X.509 v3 extensions that the default configuration file uses for non-CA certificates.
 
-The last two arguments, `-extfile` and `-extensions`, are what's needed to generate a version 3 certificate. Omitting them would generate a version 1 certificate, which works fine if your database server and client use OpenSSL, but may not work with a different SSL library. At the time of writing, both official documentations only show how to generate version 1 certificates; [MariaDB documentation](https://mariadb.com/kb/en/certificate-creation-with-openssl/) does explain the problem with version 1 certificates, promises to update the documentation soon, and then links to an unresolved [2-year-old issue](https://jira.mariadb.org/browse/MDEV-25701) about updating the documentation.
+The last two arguments, `-extfile` and `-extensions`, are what's needed to generate a version 3 certificate. Omitting them would generate a version 1 certificate, which works fine if your database server and client use OpenSSL, but may not work with a different SSL library.
+
+At the time of writing, both official documentations only show how to generate version 1 certificates; [MariaDB documentation](https://mariadb.com/kb/en/certificate-creation-with-openssl/) does explain the problem with version 1 certificates, promises to update the documentation soon, and then links to an unresolved [2-year-old issue](https://jira.mariadb.org/browse/MDEV-25701) about updating the documentation.
 
 Finally, this command just removes the certificate signing request.
 ```bash
@@ -104,23 +118,25 @@ rm "server_req.pem"
 
 ## Client Certificates
 
-Client certificates are optional. We can skip them entirely, use the same key and certificate everywhere, or generate a new key and certificate for each client (PHP application) that connects to the database server.
+Client certificates are optional. We could not use them at all, or use the same key and certificate everywhere, or generate a new key and certificate for each client (PHP application).
 
 The process for generating a client key and certificate is the same as for the server, we just need to change a few parts:
-1. Change file names, substituting `server_` for `client_` (for example).
+1. In file names, substitute `server_` for `client_` or `client_1_` or whatever else makes sense to you.
-2. Increase the serial number to `2`.
+2. Increase the serial number. The server certificate used `1`, so the first client certificate will use `2`.
-3. While technically it's unnecessary to use a different `CN` than the one used in the server certificate — as in, it will not throw errors — if someone steals your client key, they will be able to impersonate your database server by using the client key and certificate in place of the server key and certificate. By changing the `CN` to something different from your server hostname, attempting to impersonate your database server would fail, because as explained earlier, the clients check that the server certificate's `CN` field matches the server hostname.
+3. While you technically don't need to use a different `CN` than the one in the server certificate — as in, it will not throw errors — if someone steals your client key, they will be able to impersonate your database server by using the client key and certificate in place of the server key and certificate. By changing the `CN` to something different from your server hostname, attempting to impersonate your database server would fail, because as explained earlier, the clients check that the server certificate's `CN` field matches the server hostname.
 
 Here, have a convenient snippet with all three commands. Don't forget to change the `-subj`.
 ```bash
 openssl req -newkey ed25519 -nodes -subj "/C=US/O=organization/OU=organizational_unit/CN=client_name" -keyout "client_key.pem" -out "client_req.pem"
+
 openssl x509 -req -days 365000 -set_serial 2 -CA ca_cert.pem -CAkey ca_key.pem -in "client_req.pem" -out "client_cert.pem" -extfile /etc/ssl/openssl.cnf -extensions usr_cert
+
 rm "client_req.pem"
 ```
 
 ## Verify Certificates
 
-As long as you used the same file naming convention, this command will verify that the certificates are valid. The `-CAfile` argument is the same as `-CA` in the previous command, because Big Documentation needs you to never remember how commands work.
+This command will verify that one or more certificates have been signed by the CA. The `-CAfile` argument is the same as `-CA` in the previous commands, because Big Documentation needs you to never remember how commands work. Every argument after that is a path to a certificate file that we want to verify.
 ```bash
 openssl verify -CAfile ca_cert.pem server_cert.pem client_cert.pem
 ```
@@ -134,12 +150,12 @@ openssl x509 -text -noout -in client_cert.pem
 
 At this point, you should have files containing the key and certificate for the CA, server, and any number of clients you desire.
 ```
-ca_key.pem
 ca_cert.pem
-server_key.pem
+ca_key.pem
-server_cert.pem
-client_key.pem
 client_cert.pem
+client_key.pem
+server_cert.pem
+server_key.pem
 ```
 
 If you do, hooray! Make sure the files have the correct ownership and mode, pat yourself on the back, and get ready to drop into the next circle of hell.
@@ -172,11 +188,21 @@ ssl_key  = /certs/server_key.pem
 
 Restart the database server and check the logs.
 
-MySQL helpfully tells us when SSL is active: `[Server] Channel mysql_main configured to support TLS.`. It also warns us when the CA certificate is self-signed: `[Server] CA certificate ca.pem is self signed.`. Wait, `ca.pem` is **not** what we named our CA certificate file! It turns out that MySQL generates its own self-signed certificates if we don't configure your own. MySQL also silently ignores files in its configuration folders if it doesn't like them, for example files whose extension is not `.cnf`. If you see log files referring to `ca.pem` instead of the path to `ca_cert.pem` you configured, it means your configuration was not read.
+MySQL helpfully tells us when SSL is active:
+```
+[Server] Channel mysql_main configured to support TLS.
+```
 
-On the other hand, MariaDB seems to only log errors. We will see some if, for example, we are using Docker Compose, and we forgot that `docker compose restart` does not mount newly specified volumes, so the database server could not find any of the key and certificate files in `/certs`. Just a hypothetical.
+MySQL also warns us when the CA certificate is self-signed:
+```
+[Server] CA certificate ca.pem is self signed.
+```
 
-At this point, it is *possible* to connect with SSL, but not *required*. The good news is that's exactly what we (I) wanted, because SSL requirements can be set individually per database user. We can set up a test user to make sure this all works, or just use an existing user used by a service nobody will notice temporarily disappearing because something was misconfigured. Again, just a hypothetical.
+Wait, `ca.pem` is not what we named our CA certificate file! It turns out that MySQL generates its own self-signed certificates if we don't configure your own. MySQL also silently ignores files in its configuration folders if it doesn't like them, for example files whose extension is not `.cnf`. If you see log files referring to `ca.pem` instead of the path to `ca_cert.pem` you configured, it means your configuration was not read.
+
+On the other hand, MariaDB seems to only log errors when it comes to SSL configuration. We will see some if, for example, we are using Docker Compose, and we forgot that `docker compose restart` does not mount newly specified volumes, so the database server could not find any of the key and certificate files in the new `/certs` volume. Just a hypothetical.
+
+At this point, it's *possible* to connect with SSL, but it's not *required*. The good news is that's exactly what we (I) wanted, because SSL requirements can be set individually per database user, so we can set up a test user to make sure this all works. Or we could appropriate an existing user used by a service nobody will notice temporarily disappearing because something was misconfigured. Again, just a hypothetical.
 
 Before we can start requiring SSL, we need to update places that connect to our database server.
 
@@ -184,9 +210,9 @@ Before we can start requiring SSL, we need to update places that connect to our
 
 Alright, this is where a lot of the online advice gets really bad. So, here's the deal.
 
-We know that a client downloads the server certificate and checks whether it was signed by a trusted CA. How does the client know a CA is trusted? Operating systems come pre-installed with CA certificates that are trusted by the vendor of the operating system. These CAs tend to be commercial, so if you misunderstood my earlier comment to be an encouragement and splurged money on certificates from a commercial CA, it might just work out-of-the-box. However, because I have no money (unless you give me some, [hint hint nudge nudge](https://ko-fi.com/chylex)), I have not actually tested the hypothesis that things will be easier for you if you pay for a certificate, so you're on your own there.
+We know that a client downloads the server certificate and checks whether it was signed by a trusted CA. How does the client know a CA is trusted? Operating systems come pre-installed with CA certificates that are trusted by the vendor of the operating system. These CAs tend to be commercial, so if you misunderstood my earlier comment to be an encouragement and splurged money on certificates from a commercial CA, it might just work out-of-the-box. However, I have no money (unless you give me some, [wink wink nudge nudge](https://ko-fi.com/chylex)), so I haven't actually tested the hypothesis that things will be easier for you if you pay for a certificate.
 
-Any CA we made up in the course of this tutorial will certainly not be trusted by any operating system vendor. You could use a ~~magical incantation~~ command that installs our self-signed CA certificate onto the entire server. Do not. Instead, both MySQLi and PDO let us set a path to the CA certificate file before the connection is created. The provided certificate will become trusted in the context of our database connection, and will be used to verify the signature of the server certificate.
+Any CA we made up in the course of this tutorial will certainly not be trusted by any operating system vendor. You could use a ~~magical incantation~~ command to install our self-signed CA certificate onto the entire server. Do not. Instead, both MySQLi and PDO let us set a path to the CA certificate file before the connection is created. The provided certificate will become trusted in the context of our database connection, and will be used to verify the signature of the server certificate.
 
 Let's look at some examples. We will assume a folder structure with an `app` folder that is the root of your PHP application, and a `secrets` folder next to it where we can safely store secrets without any way for visitors to access them:
 - app/
@@ -196,7 +222,7 @@ Let's look at some examples. We will assume a folder structure with an `app` fol
 
 While there is no harm in putting your CA certificate somewhere your visitors could access it, there is no reason to expose them either. Besides, we might want to put *actual secrets* there later.
 
-All examples use paths relative to the PHP script file. If we have full control over the PHP server, we can place secrets into the `/certs` folder like in the example configuration for the database server. In my case, I self-host my database server, but some of my websites are managed by web hosting companies where this is not possible.
+All examples use paths relative to the PHP script file. If we have full control over the PHP server, we can place secrets into the `/certs` folder like in the example configuration for the database server. In my case, I self-host my database server, but some of my websites are on managed web hosting where this isn't possible.
 
 ### MySQLi
 
@@ -214,12 +240,12 @@ $db->real_connect(DB_HOSTNAME, DB_USERNAME, DB_PASSWORD, DB_DATABASE);
 
 The `mysqli_init` function, unlike the `mysqli` constructor, lets us configure the connection before it is established.
 
-The `ssl_set` function has a bunch of optional parameters. If we just want to get SSL working and be done with it, we only need to set the third one (`$ca_certificate`) to the path to the CA certificate file.
+The `ssl_set` function has a bunch of optional parameters. If we just want to get SSL working and be done with it, we only need to set the third one to the path to the CA certificate file.
 
 The `real_connect` function establishes a connection to the server. There is an optional [flags argument](https://www.php.net/manual/en/mysqli.real-connect.php) which has an interesting option. This is what the documentation says:
 - `MYSQLI_CLIENT_SSL`: Use SSL (encryption)
 
-It looks like you need `MYSQLI_CLIENT_SSL`, but a *different* documentation page on [mysqli constants](https://www.php.net/manual/en/mysqli.constants.php) expands the description with:
+It looks like you need `MYSQLI_CLIENT_SSL`, but the documentation page on [mysqli constants](https://www.php.net/manual/en/mysqli.constants.php) expands the description with:
 - `MYSQL_CLIENT_SSL`: Use SSL (encrypted protocol). This option should not be set by application programs; it is set internally in the MySQL client library
 
 The end goal is to configure the *database server* to require SSL for your `DB_USERNAME`, so we will be sure SSL is active even when we don't specify the `MYSQLI_CLIENT_SSL` flag as half of the documentation suggests.
@@ -275,9 +301,11 @@ foreach ($db->query('SHOW STATUS LIKE \'Ssl_%\'', PDO::FETCH_ASSOC)->fetchAll()
 
 ## Use Client Key & Certificate
 
-For most people, just getting SSL to work at all is enough. However, if we wanted to strengthen security even more, we could use a client key and certificate. Similarly to how the client can verify the server's identity using the server certificate, the server is able to verify the client's identity using the client certificate. Assuming our client key and certificate has been generated, we will need to put the `client_key.pem` and `client_cert.pem` files somewhere our PHP script can access them — for example, into the `secrets` folder, next to the `ca_cert.pem` file. The rest is easy — we just add a few additional parameters or options in the functions we are already calling.
+For most people, just getting SSL to work at all is enough. However, if we wanted to strengthen security even more, we could use a client key and certificate.
 
-## MySQLi
+Similarly to how the client can verify the server's identity using the server certificate, the server is able to verify the client's identity using the client certificate. Assuming we have a client key and certificate, we will need to put the `client_key.pem` and `client_cert.pem` files somewhere our PHP script can access them — for example, into the `secrets` folder, next to the `ca_cert.pem` file. The rest is easy — we just add a few additional arguments or options in the functions we are already calling.
+
+### MySQLi
 
 **Before:**
 ```php
@@ -315,27 +343,27 @@ $db = new PDO('mysql:host='.DB_HOSTNAME.';dbname='.DB_DATABASE.';charset=utf8mb4
 
 With SSL working, we should require a user on the database server to use SSL for every connection.
 ```sql
-ALTER USER 'my_user'@'%' REQUIRE SSL
+ALTER USER 'username'@'%' REQUIRE SSL
 ```
 
 The next, optional step could be to require the database user to connect with any valid client certificate.
 ```sql
-ALTER USER 'my_user'@'%' REQUIRE X509
+ALTER USER 'username'@'%' REQUIRE X509
 ```
 
 We could require client certificates to have a specific "subject" (contents of the `-subj` argument earlier). If we took the earlier example command for generating a client certificate literally, the subject of the certificate would be `/C=US/O=organization/OU=organizational_unit/CN=client_name` and the SQL command to require it would look like this:
 ```sql
-ALTER USER 'my_user'@'%' REQUIRE SUBJECT '/C=US/O=organization/OU=organizational_unit/CN=client_name'
+ALTER USER 'username'@'%' REQUIRE SUBJECT '/C=US/O=organization/OU=organizational_unit/CN=client_name'
 ```
 
 Finally, we could not only require a specific "subject" for the client certificate, but also for the CA certificate that signed it. Again, using the earlier example literally, if the subject of the CA certificate is `/C=US/O=organization/OU=organizational_unit/CN=common_name` then the SQL command will look like this:
 ```sql
-ALTER USER 'my_user'@'%' REQUIRE SUBJECT '/C=US/O=organization/OU=organizational_unit/CN=client_name' AND ISSUER '/C=US/O=organization/OU=organizational_unit/CN=common_name'
+ALTER USER 'username'@'%' REQUIRE SUBJECT '/C=US/O=organization/OU=organizational_unit/CN=client_name' AND ISSUER '/C=US/O=organization/OU=organizational_unit/CN=common_name'
 ```
 
-Actually, I lied — there's even more possibilities. We could, for example, require the client to use a specific cipher. The [MariaDB documentation](https://mariadb.com/kb/en/securing-connections-for-client-and-server/#requiring-tls-for-specific-user-accounts-from-specific-hosts) covers this. However, the defaults — especially with TLSv1.3 — should be fine.
+Actually, I lied — there's even more possibilities. We could, for example, require the client to use a specific cipher. [MariaDB documentation](https://mariadb.com/kb/en/securing-connections-for-client-and-server/#requiring-tls-for-specific-user-accounts-from-specific-hosts) covers this. However, the defaults — especially with TLSv1.3 — should be fine.
 
-## Do not Disable Server Certificate Verification
+## Do Not Disable Server Certificate Verification
 
 Using the `MYSQLI_CLIENT_SSL_DONT_VERIFY_SERVER_CERT` flag or setting the `PDO::MYSQL_ATTR_SSL_VERIFY_SERVER_CERT` flag to `false` is often recommended by online tutorials or stackoverflow answers if you "run into problems", as a way to "fix those problems".
 
@@ -349,7 +377,7 @@ If anyone has a legitimate reason to disable server certificate verification, do
 
 When we enable SSL, we lose some performance because the client and server have to do some additional work. Out of curiosity, I measured how long it takes to establish a connection to the database server with various compression algorithms — including RSA with various key sizes, in case you were curious — or cannot use Ed25519 for some reason, and are stuck with RSA. My web server is on a shared web hosting, and my database server is self-hosted. I took 200 samples for every configuration, and used [Statistics Kingdom](https://www.statskingdom.com) to make a box plot:
 
-![Box plot showing the performance of No SSL, Ed25519, and RSA with 2048-bit, 3072-bit, and 4096-bit key sizes.]({{ '/assets/img/mysql-ssl-guide/performance.png' | relative_url }})
+![Box plot showing the performance of No SSL, Ed25519, and RSA with 2048-bit, 3072-bit, and 4096-bit key sizes.]({{ '/assets/img/ultimate-guide-to-mysql-ssl/performance.png' | relative_url }})
 
 The same plot in table form, ordered by median time:
 
@@ -369,4 +397,6 @@ Note that I did not measure the performance impact of encrypting and decrypting
 
 # 5. Wow, Security
 
-I hope this has been helpful. If you noticed any problems with the post, don't hesitate to post a comment. If this post saved you some frustration (probably not time considering its length), you can share it and/or support me on [Ko-fi](https://ko-fi.com/chylex).
+I hope this has been helpful. If you noticed any problems with the post, don't hesitate to post a comment.
+
+If this post saved you some frustration (although probably not time, considering its length), you can share it and/or support me on [Ko-fi](https://ko-fi.com/chylex).

_posts/2025-04-22-jetbrains-writerside-eap-expiration-bypass.md

@@ -0,0 +1,118 @@
+---
+title: "JetBrains Writerside EAP Expiration Bypass"
+subtitle: "%pub"
+date: 2025-04-22
+commentid: 5
+---
+
+JetBrains has [discontinued the Writerside IDE](https://blog.jetbrains.com/writerside/2025/03/sunsetting-writerside-ide/) in favor of the Writerside plugin. Since the IDE has always been in the Early Access Program (EAP), its builds expire after 30 days, meaning they can’t be used indefinitely. Personally, I prefer a separate IDE for writing documentation, and the plugin has some UX annoyances I don't want to deal with, so let's bypass the EAP expiration!
+
+I’m using Writerside 2024.3 EAP (243.22562.371), but the guide should give you enough information to adapt to changes in other versions.
+
+# Finding the Expiration Check
+
+![Dialog shown when opening an expired build of Writerside EAP]({{ '/assets/img/jetbrains-writerside-eap-expiration-bypass/expiration-dialog.png' | relative_url }})
+
+Writerside, like other JetBrains IDEs, uses Java Swing. That makes it easy to find the code used to show a modal dialog — such as the one warning you that the EAP build expired. Every modal dialog spawns an event loop, which will appear in the stack trace.
+
+Once Writerside is running and the "Writerside EAP Build Expired" dialog is visible, find the process ID (PID) and run `jstack <pid>` to dump the stack trace. You can use `jstack` from Writerside's installation directory:
+
+```cmd
+%LOCALAPPDATA%\Programs\Writerside\jbr\bin\jstack.exe 12345
+```
+
+Look for the `AWT-EventQueue-0` thread. I highlighted the important parts of the stack trace with arrows.
+
+```stacktrace
+"AWT-EventQueue-0" #72 [21032] prio=6 os_prio=0 cpu=1031.25ms elapsed=323.16s tid=0x0000019c1a2f3c40 nid=21032 waiting on condition  [0x0000009afb8fc000]
+   java.lang.Thread.State: WAITING (parking)
+        (unimportant lines)
+        at java.awt.EventQueue.getNextEvent(java.desktop/EventQueue.java:573)
+        at com.intellij.ide.IdeEventQueue.getNextEvent(IdeEventQueue.kt:466)
+        at java.awt.EventDispatchThread.pumpOneEventForFilters(java.desktop/EventDispatchThread.java:194)
+        at java.awt.EventDispatchThread.pumpEventsForFilter(java.desktop/EventDispatchThread.java:128)
+        at java.awt.EventDispatchThread.pumpEventsForFilter(java.desktop/EventDispatchThread.java:121)
+        at java.awt.WaitDispatchSupport$2.run(java.desktop/WaitDispatchSupport.java:191)
+        at java.awt.WaitDispatchSupport$4.run(java.desktop/WaitDispatchSupport.java:236)
+        at java.awt.WaitDispatchSupport$4.run(java.desktop/WaitDispatchSupport.java:234)
+        at java.security.AccessController.executePrivileged(java.base@21.0.5/AccessController.java:778)
+        at java.security.AccessController.doPrivileged(java.base@21.0.5/AccessController.java:319)
+        at java.awt.WaitDispatchSupport.enter(java.desktop/WaitDispatchSupport.java:234)
+    --> at java.awt.Dialog.show(java.desktop/Dialog.java:1079)
+        at com.intellij.openapi.ui.impl.DialogWrapperPeerImpl$MyDialog.show(DialogWrapperPeerImpl.java:890)
+        at com.intellij.openapi.ui.impl.DialogWrapperPeerImpl.show(DialogWrapperPeerImpl.java:472)
+        at com.intellij.openapi.ui.DialogWrapper.doShow(DialogWrapper.java:1772)
+        at com.intellij.openapi.ui.DialogWrapper.show(DialogWrapper.java:1721)
+        at com.intellij.ui.messages.AlertMessagesManager.showMessageDialog(AlertMessagesManager.kt:70)
+        at com.intellij.ui.messages.MessagesServiceImpl.showMessageDialog(MessagesServiceImpl.java:54)
+        at com.intellij.openapi.ui.Messages.showDialog(Messages.java:274)
+        at com.intellij.openapi.ui.Messages.showDialog(Messages.java:290)
+        at com.intellij.openapi.ui.Messages.showDialog(Messages.java:305)
+    --> at com.intellij.ide.V.a.VP.p(VP.java:320)
+    --> at com.intellij.ide.V.a.VP.H(VP.java:308)
+        at com.intellij.ide.V.a.VP$$Lambda/0x0000019ba1c3ab78.run(Unknown Source)
+        (unimportant lines)
+```
+
+The top of the stack trace is processing an event queue spawned by `java.awt.Dialog.show`. A few lines below is the main point of interest — two methods related to the expiration check, that made the dialog appear: `com.intellij.ide.V.a.VP.p` and `com.intellij.ide.V.a.VP.H`.
+
+# Patching the Expiration Check
+
+To remove the expiration check, I will use [Recaf](https://github.com/Col-E/Recaf) 2.21.4.
+
+To save you some time, the `VP` class is found inside `Writerside/lib/product.jar`. On Windows, this would be in `%LOCALAPPDATA%\Programs\Writerside\lib\`.
+
+Open `product.jar` in Recaf and search for `com/intellij/ide/V/a/VP`.
+
+![Screenshot of Recaf with the searched class]({{ '/assets/img/jetbrains-writerside-eap-expiration-bypass/recaf-class.png' | relative_url }})
+
+Opening the class will attempt to decompile it. Due to heavy obfuscation, the decompiled code or line numbers from the stack trace are mostly useless, so right-click the `VP` tab and switch to the Table view.
+
+The `p` method that calls `Messages.showDialog` can be difficult to find since its name is shared with several other methods, but the `H` method is unique.
+
+![Screenshot of Recaf with the searched method]({{ '/assets/img/jetbrains-writerside-eap-expiration-bypass/recaf-method.png' | relative_url }})
+
+Right-click the `H` method, select "Edit with assembler", and replace everything after the first line with `RETURN`. Press `Ctrl+S` to save, and close the editor.
+
+```
+DEFINE PRIVATE SYNTHETIC H()V
+RETURN
+```
+
+> In Recaf 4, you can use the "Edit - Make no-op" option in the context menu instead.
+
+Use "File - Export program" to export the patched `product.jar`, and replace the original file. You should now be able to use Writerside forever!
+
+# Addendum: Fixing the Git Tool Window
+
+The 243.22562.371 build of Writerside has an annoying bug, where the Git tool window doesn't show a diff preview depending on its location. This was caused by [commit c456622](https://github.com/JetBrains/intellij-community/commit/c4566222c3c4ca2bb08080ae3d476d65331a8ec4), and is also easy to fix using Recaf.
+
+The buggy code is in `Writerside/lib/modules/intellij.platform.vcs.impl.jar`, in these two classes:
+- `com/intellij/openapi/vcs/changes/ChangesViewManager$ChangesViewToolWindowPanel`
+- `com/intellij/openapi/vcs/changes/shelf/ShelvedChangesViewManager$ShelfToolWindowPanel`
+
+Both classes have an `updatePanelLayout` method that calls `ChangesViewContentManager.isToolWindowTabVertical`, stores the result in a local variable, and hides the preview diff if the variable is `true`.
+
+```java
+boolean isVertical = isToolWindowTabVertical(myProject, LOCAL_CHANGES);
+boolean hasSplitterPreview = !isVertical;
+```
+
+Edit each `updatePanelLayout` method with assembler and search for the `isToolWindowTabVertical` call. The surrounding bytecode instructions are almost the same in both classes.
+
+```
+ALOAD this
+GETFIELD com/intellij/openapi/vcs/changes/ChangesViewManager$ChangesViewToolWindowPanel.myProject ...
+LDC "Local Changes"
+INVOKESTATIC com/intellij/openapi/vcs/changes/ui/ChangesViewContentManager.isToolWindowTabVertical(...)Z
+ISTORE isVertical
+```
+
+Replace these instructions — except for the `ISTORE` instruction — with `ICONST_0`, and save.
+
+```
+ICONST_0
+ISTORE isVertical
+```
+
+This forces the `isVertical` variable to always be `false`, preventing the preview diff from being hidden.

assets/css/style.scss

@@ -62,6 +62,10 @@
     margin-top: 0.2rem;
   }
   
+  pre code {
+    white-space: pre-wrap;
+  }
+  
   .page-breadcrumbs {
     margin: -0.75rem 0 -0.25rem;
     font-size: 1.05rem;