David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2019-07-08 📝 Original message: On Fri, Jul 05, 2019 at ...
📅 Original date posted:2019-07-08
📝 Original message:
On Fri, Jul 05, 2019 at 03:36:37AM +0000, ZmnSCPxj via Lightning-dev wrote:
> A client can easily DoS the server by requesting and requesting (thus
> convincing the server to encrypt and send data immediately) and never
> paying.
Is this an actual concern? Assuming this protocol is used with web apps
for sites that are available over HTTPS, the client can just request the
order form page over and over to also waste server CPU encrypting and
bandwidth transfering (or they could use more clever ways to abuse TLS).
For the case of a downloaded file, the server can encrypt immediately
before it puts data in the TCP queue so that, if the socket blocks
(because the client isn't downloading), it only wasted CPU encrypting a
few more blocks than were actually delivered.
-Dave
📝 Original message:
On Fri, Jul 05, 2019 at 03:36:37AM +0000, ZmnSCPxj via Lightning-dev wrote:
> A client can easily DoS the server by requesting and requesting (thus
> convincing the server to encrypt and send data immediately) and never
> paying.
Is this an actual concern? Assuming this protocol is used with web apps
for sites that are available over HTTPS, the client can just request the
order form page over and over to also waste server CPU encrypting and
bandwidth transfering (or they could use more clever ways to abuse TLS).
For the case of a downloaded file, the server can encrypt immediately
before it puts data in the TCP queue so that, if the socket blocks
(because the client isn't downloading), it only wasted CPU encrypting a
few more blocks than were actually delivered.
-Dave