diff --git a/ChangeLog.d/l13-hw-accel.txt b/ChangeLog.d/l13-hw-accel.txt
new file mode 100644
index 0000000..53c7924
--- /dev/null
+++ b/ChangeLog.d/l13-hw-accel.txt
@@ -0,0 +1,7 @@
+Security
+   * Fix issue in Lucky 13 counter-measure that could make it ineffective when
+     hardware accelerators were used (using one of the MBEDTLS_SHAxxx_ALT
+     macros). This would cause the original Lucky 13 attack to be possible in
+     those configurations, allowing an active network attacker to recover
+     plaintext after repeated timing measurements under some conditions.
+     Reported and fix suggested by Luc Perneel in #3246.
diff --git a/library/ssl_tls.c b/library/ssl_tls.c
index 60357e2..25a43bb 100644
--- a/library/ssl_tls.c
+++ b/library/ssl_tls.c
@@ -2092,10 +2092,20 @@
             ssl_read_memory( ssl->in_msg + ssl->in_msglen, padlen );
             mbedtls_md_hmac_finish( &ssl->transform_in->md_ctx_dec, mac_expect );
 
-            /* Call mbedtls_md_process at least once due to cache attacks
-             * that observe whether md_process() was called of not */
+            /* Dummy calls to compression function.
+             * Call mbedtls_md_process at least once due to cache attacks
+             * that observe whether md_process() was called of not.
+             * Respect the usual start-(process|update)-finish sequence for
+             * the sake of hardware accelerators that might require it. */
+            mbedtls_md_starts( &ssl->transform_in->md_ctx_dec );
             for( j = 0; j < extra_run + 1; j++ )
                 mbedtls_md_process( &ssl->transform_in->md_ctx_dec, ssl->in_msg );
+            {
+                /* The switch statement above already checks that we're using
+                 * one of MD-5, SHA-1, SHA-256 or SHA-384. */
+                unsigned char tmp[384 / 8];
+                mbedtls_md_finish( &ssl->transform_in->md_ctx_dec, tmp );
+            }
 
             mbedtls_md_hmac_reset( &ssl->transform_in->md_ctx_dec );