internetstandards
Rejected connections will skew test results
https://github.com/internetstandards/Internet.nl/blob/426bd58dc1878e3e5d236e24777f8e9b7b0e0f6c/checks/tasks/tls_connection_exceptions.py#L1
Placeholders appear to have been created to handle TLS Connection Exceptions, however the error handling has not been implemented. Is this a reason why Internet NL returns a low score for a service that has implemented rate-limiting or validation of the source of incoming traffic?
Rate limiting indeed results in an TLS error, and therefor lower score. Note that currently there is a refactor concerning the TLS:
- #1218
The goal is to be IDS friendly and not to trigger rate limiting, since this will result In the tool not being useful.
The question is: when is it reasonable when a TLS setup no longer works? What would you consider a normal TLS exception? I know the HTTPS 429 rate limit code, but what is a valid way to do this on TLS? I think regular 'TLS rate limiting' works with a REJECT or DROP on TCP level? Is there something to distinguish between an error and rate limiting? How many connections are reasonable?
When a server rejects a connection request, it may close the connection abruptly (EOF). Is this something to look for and return to the test?
Can you point me to some RFC's that this may be done in this way? (e.g. why not prefer a delayed connection setup / response or a TCP reject?) What do you propose the test should do if there is a connection abrupt disconnect?