Fix newlines in PSF-2023-8

advisories/python/PSF-2023-8.json

@@ -7,7 +7,7 @@
     "CVE-2023-40217"
   ],
   "summary": "Bypass TLS handshake on closed sockets",
-  "details": "Instances of `ssl.SSLSocket` are vulnerable to a bypass of the TLS handshake and included protections (like certificate verification) and treating sent unencrypted data as if it were post-handshake TLS encrypted data.\\n\\nThe vulnerability is caused when a socket is connected, data is sent by the malicious peer and stored in a buffer, and then the malicious peer closes the socket within a small timing window before the other peers’ TLS handshake can begin. After this sequence of events the closed socket will not immediately attempt a TLS handshake due to not being connected but will also allow the buffered data to be read as if a successful TLS handshake had occurred.\\n\\n\\n### Affected usages\\n\\nThis vulnerability **primarily affects** HTTPS servers and other server-side protocols using TLS client authentication due to requiring reading data immediately after the handshake to be vulnerable. Operations which would fail on a closed socket (like sending data) immediately after the handshake **are not affected by this vulnerability.**\\n\\nBecause disconnecting the socket is a necessary step to trigger the vulnerability **there is no risk of data exfiltration or data leakage directly from the malicious TLS connection**, however the vulnerability does carry risk for modifying or deleting resources which are authenticated using only TLS client certificates.\\n\\nThis vulnerability **affects** clients who are reading and processing data from the server after a TLS handshake without sending any data first. Our team is unaware of a protocol that uses TLS that fits this usage pattern.\\n\\nThis vulnerability **does not affect** client-side HTTPS connections like pip or requests as an HTTP request must be sent before an HTTP response is read meaning the connection would already be closed by the time the client is sending an HTTP request, leading to an error.\\n\\nThis vulnerability **affects, but has no impact** on servers that aren’t using TLS client certificate authentication as traffic to a non-authenticating TLS server loses nothing from a bypassed handshake to inject a query and close the connection as the same action could be taken by a peer using a TLS connection with a proper handshake.",
+  "details": "Instances of `ssl.SSLSocket` are vulnerable to a bypass of the TLS handshake and included protections (like certificate verification) and treating sent unencrypted data as if it were post-handshake TLS encrypted data.\n\nThe vulnerability is caused when a socket is connected, data is sent by the malicious peer and stored in a buffer, and then the malicious peer closes the socket within a small timing window before the other peers’ TLS handshake can begin. After this sequence of events the closed socket will not immediately attempt a TLS handshake due to not being connected but will also allow the buffered data to be read as if a successful TLS handshake had occurred.\n\n### Affected usages\n\nThis vulnerability **primarily affects** HTTPS servers and other server-side protocols using TLS client authentication due to requiring reading data immediately after the handshake to be vulnerable. Operations which would fail on a closed socket (like sending data) immediately after the handshake **are not affected by this vulnerability.**\n\nBecause disconnecting the socket is a necessary step to trigger the vulnerability **there is no risk of data exfiltration or data leakage directly from the malicious TLS connection**, however the vulnerability does carry risk for modifying or deleting resources which are authenticated using only TLS client certificates.\n\nThis vulnerability **affects** clients who are reading and processing data from the server after a TLS handshake without sending any data first. Our team is unaware of a protocol that uses TLS that fits this usage pattern.\n\nThis vulnerability **does not affect** client-side HTTPS connections like pip or requests as an HTTP request must be sent before an HTTP response is read meaning the connection would already be closed by the time the client is sending an HTTP request, leading to an error.\n\nThis vulnerability **affects, but has no impact** on servers that aren’t using TLS client certificate authentication as traffic to a non-authenticating TLS server loses nothing from a bypassed handshake to inject a query and close the connection as the same action could be taken by a peer using a TLS connection with a proper handshake.",
   "affected": [
     {
       "ranges": [