network profile
| bio | website | |
|---|---|---|
| location | Sweden | |
| age | 40 | |
| visits | member for | 4 months |
| seen | May 2 at 22:26 | |
| stats | profile views | 8 |
|
May 2 |
comment |
Lessen impact of DoS attack on cpu-expensive login? it would be sufficient for an attacker to hog enough bandwidth so that client ping packets would be delayed. That would cause the server to boot them off the server. However, resuming connections fixes that issue. Will you add that to the answer and I'll accept it. |
|
Apr 30 |
comment |
Lessen impact of DoS attack on cpu-expensive login? Just so it's clear. This is not a web server, it's plain socket with a custom protocol. The server itself will have connections to a large amount of clients (1000-10000). Even with a proof-of-work, these legitimate clients can cause problems. A particular weakness would be if the attempted attack simply causes lots of disconnects to clients. The legitimate client reconnects might be sufficient to bring down the server, even if all the attack succeeds in is disconnecting a % of all clients. This problem is very different from non-persistent connections. |
|
Apr 30 |
comment |
Lessen impact of DoS attack on cpu-expensive login? The underlying problem DDoS or rapid reconnects, is that the handshake immediately incur a great CPU cost. Looking at the DDoS case, it's about how many attacks that need to get through in order to destabilize the system. This number is the same number of rapid reconnects that the server can sustain. Reducing the number of DDoS attackers is good, but reducing the sensitivity to rapid logins is as important. The reason this is a security question is because it's the security handshake that leaves the server open. I'm looking for alternate methods that do not exhibit the same weakness. |
|
Apr 30 |
comment |
Lessen impact of DoS attack on cpu-expensive login? I don't see this helping any against legitimate rapid reconnects. |
|
Apr 30 |
comment |
Lessen impact of DoS attack on cpu-expensive login? Given the current handshake protocol, there's no problem for a machine to send legitimate packets and in that way paralyse the server. So the issue is primarily about massive reconnect working in-effect as a short duration DDoS attack, with hardening the server against malicious, sustained DDoS only as a secondary consideration. |
|
Apr 30 |
comment |
Lessen impact of DoS attack on cpu-expensive login? @НЛО Impractical due to the added complexity. As explained, this is plain socket communication. Adding a protocol negotiating if the client is allowed encrypted communications doesn't just make the handshake very complex, but the number of states in the client to present the captcha is daunting, especially considering that the client will also connect to two different servers in sequence. And again, this doesn't protect from the scenario of a rapid reconnect due to network or server glitches. |
|
Apr 30 |
comment |
Lessen impact of DoS attack on cpu-expensive login? How is an identifier different from just checking and blocking IPs that are flooding with requests? |
|
Apr 29 |
comment |
Lessen impact of DoS attack on cpu-expensive login? @Adnan I tried to clarify it in the edit, clear enough? |
|
Apr 29 |
comment |
Lessen impact of DoS attack on cpu-expensive login? I don't really understand at what stage you suggest I do this. |
|
Apr 29 |
comment |
Prevent DOS against RSA authentication Well, that's something the server could handle without a ping packet. Basically, it could spin off the decryption on a queue and stay responsive. If the queue would grow, that request could simply cancel and send back a "server login overloaded" message. |
|
Apr 28 |
comment |
Prevent DOS against RSA authentication - and another annoying thing is that ECC encryption isn't as widely supported as RSA. For the iOS client this means adding the entire OpenSSL lib in order to get hold of it. |
|
Apr 27 |
comment |
Prevent DOS against RSA authentication What would the ping add? What's the difference in sending ping->connect(rsa-encrypted payload) and just sending connect(rsa-encrypted-payload)? Seems to me that they would be virtually equivalent. |
|
Apr 27 |
comment |
Prevent DOS against RSA authentication With RSA I can issue the clients the public key, and they can trust that whoever manages to decrypt the message is someone who owns the private key. Can ECDH work in a similar manner? Even though speeding up validation is good, it's not really eliminating the underlying weakness. Will you have a look at the strategies I added in my edit? |
|
Dec 31 |
comment |
Share or not share public key for servers? Just so that it's clear: The client may authenticate itself, but only over the secured connection after the encrypted channel is created (i.e. stage 2 is completed). However, not all requests to the lobby require authentication, e.g. registration. (Lobby requests are also stateless, so authentication may occur multiple times) |
