william-stacken / tiriryarai Goto Github PK

The logs are encrypted and may as well be compressed too unless it introduces a large performance overhead.

I would be useful to be able to rate limit and/or block IPs that send excessive amounts of requests, especially clients that attempt to brute force the basic authentication. Timeouts should also be implemented if a client opens a connection that becomes inactive.

Tiriryarai has only been tested manually. Automated testing with CI should be set up.

In case Tiriryarai is hosted on an untrusted system, logs and PKCS12 files should be encrypted since they can potentially contain sensitive information. Furthemore, logs to stdout should instead be logged to an encrypted file.

SharpZipLib could be used to Zip each log with the password given as an argument to the program, and the PCKS12 files could use the password given instead of the subpar "secret" password. But in that case, the password must be hidden somehow from the terminal when starting Tiriryarai.

Add OCSP Stapling support, will probably require BouncyCastle.

One such header is Accept-Ranges with 206 Partial Content which makes it faster to resume a download of large files. Tiriryarai could also be updated to respect the Accept header sent by the client, and potentially send a 406 Not Acceptable .

Tiriryarai currently has a limit for how long request lines can be, but not entity bodies, and 400 Bad Request is used instead of the more specific 414 URI Too Long. An entity body limit limit should probably be introduced along with a 413 Payload Too Large to prevent infinite data streams to be sent to it.

For privacy, log filenames should be encrypted. But it should not be in a way that compromises the strength of the encryption scheme for the log contents. It should preferably also not increase the performance overhead too much.

One option is to generate a 16-byte IV, concatenate it with the AES-256-CBC encrypted filename, and base64 encode it. You could then decrypt all filenames by decoding the base64, treating the first 16 bytes as the IV, and the remainder as the encrypted filename. This means finding a particular log file turns into an O(n) operation since all files must be decrypted one by one until the correct file is found.

This would be useful if Tiriryarai is hosted on the public internet.

The user should be able to specify how much logging should take place. There should also be different debug modes for what to print to the console.

The HTTP body is stored in HttpMessage.cs as a byte array, which is not ideal since it increases memory usage when transfering a lot of data. Maybe this could be solved by optionally setting a filepath or a stream that the body can be read from or written to instead?

This would make it possible to remove the ReadLog method from Logger.cs and replace it with a "WriteLogToStream" method instead, improving memory usage.

Certificates should not be ignored by default in HttpsClient.cs by default since it poses a security risk.

All HTTP messages in Tiriryarai are assumed to be version 1.1. 1.0 should be supported where the connection is assumed to close unless stated otherwise. There is also the possibliity of implementing HTTP2 support in both HttpsMitmProxy and HttpsClient

It should be evaluated if it's useful or if it could just be added for completeness sake.

If an HTML document that contains references to remote resources, such as img tags, is present in the logs inside of an iframe, the web browser will start to generate a bunch of requests. Ideally, this should not be done since it increases the logs while simply viewing them. Either a way to stop the requests should be found, or the way HTML docs are put in iframes should be reconsidered.

Test building and running Tiriryarai on Windows and append instructions to README.

Add support to download the source code from the web interface and switch license to Affero GPL.