Further minor changes to word order, syntax and spelling to improve readability of the Tips and Tricks section.

TLS.md

@@ -57,17 +57,17 @@ Thanks to BearSSL's compactness and aggressive optimization, the minimal TLS con
 
 Here are the tips and tricks used to reduce Flash and Memory:
 
-* **MFLN**: TLS normally uses 16k buffers for send and receive. 32k looks very small on a server but immensly huge for ESP8266. TLS 1.2 introduced MFLN (Maximum Fragment Length Negociation) which allows the TLS Client to reduce both buffers down to 512 bytes. MFLN is not widely supported yet, but it is by recent OpenSSL versions and by AWS IoT. This is a huge improvement in memory footprint. If your server does not support MFLN, it will still work as long as the messages sent by the server do not exceed the buffer length. In Tasmota the buffer length is 1024 bytes for send buffer and 1024 bytes for receive buffer. Goind below creates message fragmentation and much longer TLS connection time (above 3s). If your server does not support MFLN, you'll see a message in the logs.
-* **Max Certicate size**: BearSSL normally supports server certificate up to RSA 4096 bits and EC 521 bits. These certificate are very uncommon currently. To save extra memory, the included BearSSL library is trimmed down to maximum RSA 2048 bits certificate and EC 256 bits certiticates. This should not have any impact for you.
-* **EC private key**: AWS IoT requires the client to authenticate with its own Private Key and Certificate. By default AWS IoT will generate a RSA 2048 bits private key. In Tasmota, we moved to an EC (Elliptic Curve) Private Key of 256 bits. EC keys are much smaller, and handshake is significantly faster. Note: the key being 256 bits does not mean it's less secure than RSA 2048, it's actually the opposite.
-* **Single Cipher**: to reduce code size, we only support a single TLS cipher and embed only the code strictly necessary. When using TLS (e.g. Letsencrypt on Mosquitto) the supported cipher is `RSA_WITH_AES_128_GCM_SHA256` which is a very commonly supported cipher. For AWS IoT, the only supported cipher if `ECDHE_RSA_WITH_AES_128_GCM_SHA256` which is one of the recommended ciphers. Additionally, ECDHE offers Perfect Forward Secrecy which means extra security.
-* **Adaptative Thunk Stack**: BearSSL does not allocate memory on its own. It's either the caller's responsibility or memory is taken on the Stack. Stack usage can go above 5k, more than the ESP8266 stack. Arduino created a **Thunk Stack**, a secondary stack of 5.6k, allocated on Heap, and activated when a TLS connection is active. Actually the stack is mostly used during TLS handshake, and much less memory is required during TLS message processing. Tasmota only allocates the Thunk Stack during TLS handshake and swithes back to normal Stack afterwards. See below about actual memory usage.
+* **MFLN** (Maximum Fragment Length Negotiation): TLS normally uses 16k buffers for send and receive. 32k looks very small on a server, but immensely huge for ESP8266. TLS 1.2 introduced MFLN, which allows the TLS Client to reduce both buffers down to 512 bytes. MFLN is not widely supported yet, but it is by recent OpenSSL versions and by AWS IoT. This is a huge improvement in memory footprint. If your server does not support MFLN, it will still work as long as the messages sent by the server do not exceed the buffer length. In Tasmota the buffer length is 1024 bytes for send buffer and 1024 bytes for receive buffer. Going below creates message fragmentation and much longer TLS connection times (above 3s). If your server does not support MFLN, you'll see a message to that effect in the logs.
+* **Max Certicate size**: BearSSL normally supports server certificates of up to RSA 4096 bits and EC 521 bits. These certificates are very uncommon currently. To save extra memory, the included BearSSL library is trimmed down to maximum RSA 2048 bit certificate and EC 256 bit certificate. This should not have any impact for you.
+* **EC private key**: AWS IoT requires the client to authenticate with its own Private Key and Certificate. By default AWS IoT will generate an RSA 2048 bit private key. In Tasmota, we moved to an EC (Elliptic Curve) Private Key of 256 bits. EC keys are much smaller, and handshake is significantly faster. Note: the key being 256 bits does not mean it's less secure than RSA 2048, it's actually the opposite.
+* **Single Cipher**: to reduce code size, we only support a single TLS cipher and embed only the code strictly necessary. When using TLS (e.g. Letsencrypt on Mosquitto) the supported cipher is `RSA_WITH_AES_128_GCM_SHA256` which is a very commonly supported cipher. For AWS IoT, the only supported cipher is `ECDHE_RSA_WITH_AES_128_GCM_SHA256` which is one of the recommended ciphers. Additionally, ECDHE offers Perfect Forward Secrecy which means extra security.
+* **Adaptative Thunk Stack**: BearSSL does not allocate memory on its own. It's either the caller's responsibility or memory is taken on the Stack. Stack usage can go above 5k, more than the ESP8266 stack. Arduino created a **Thunk Stack**, a secondary stack of 5.6k, allocated on Heap, and activated when a TLS connection is active. Actually the stack is mostly used during TLS handshake, and much less memory is required during TLS message processing. Tasmota only allocates the Thunk Stack during TLS handshake and switches back to the normal Stack afterwards. See below for details of actual memory usage.
 * **Keys and CA in PROGMEM**: BearSSL was adapted from original source code to push most on the tables and static data into PROGMEM:
-https://github.com/earlephilhower/bearssl-esp8266. Additional work let us now to put Client Private Key, Certificate and CA in PROGMEM, saving at leas 3k of Memory.
+https://github.com/earlephilhower/bearssl-esp8266. Additional work now allows us to put the Client Private Key, Certificate and CA in PROGMEM too, saving at least 3k of Memory.
 
 ### Memory usage
 
-TLS on Tasmota has been aggresively optimised to use as little memory (heap) as possible. It was also optimized to limit code size.
+TLS on Tasmota has been aggressively optimized to use as little memory (heap) as possible. It was also optimized to limit code size.
 
 Memory consumption (nominal):
 
@@ -76,7 +76,7 @@ Memory consumption (nominal):
 * Buffers (1024 bytes in + 1024 bytes out + overhead): **2528 bytes**
 * **Total = 7.4k** (or 7.0k with letsencrypt or regular TLS)
 
-Note: if you use USE_WEBSERVER, your impact is lowered by 2k since the Web log buffer is reduced from 4k to 2k. Overall when activating USE_WEBSERVER, you just see a memory impact of 5.4k.
+Note: if you use USE_WEBSERVER, your impact is lowered by 2k since the Web log buffer is reduced from 4k to 2k. Overall, when activating USE_WEBSERVER, you just see a memory impact of 5.4k.
 
 Memory needed during connection (TLS handshake - fingerprint validation):
 
@@ -92,7 +92,7 @@ Memory needed during connection (TLS handshake - full CA validation):
 
 ### Connection Time
 
-ESP8266 is quite slow compared to modern processors when it comes to SSL handshake. Here are the observed performance to connect to an SSL/TLS server, depending on frequency (80MHz or 160MHz):
+The ESP8266 is quite slow compared to modern processors when it comes to SSL handshakes. Here are the observed performance times when connecting to an SSL/TLS server, depending on the CPU frequency (80MHz or 160MHz):
 
 AWS IoT Connection, with EC Private Key, simple fingerprint validation:
 
@@ -116,7 +116,7 @@ Letsencrypt based server (Mosquitto for ex), with full CA validation (easier to
 
 ### TLS Troubleshooting
 
-Here are the common TLS error:
+Here are the most common TLS errors:
 
 Error code | Description
 :---		 | :---
@@ -124,7 +124,7 @@ Error code | Description
 | -1000 | Out of memory error |
 | 1 | Bad fingerprint |
 | 62 | X509 not trusted, the server certificate is not signed by the CA (AWS IoT or Letsencrypt) |
-| 298 | missing client private key |
+| 298 | Missing client private key |
 
 -----------