http and http2 log entry on server side when clien considers tls certificate unsafe / untrusted

[hartwig]

Hi,

when serving an untrusted / wrong hostname tls certificate from go server, I get the following log entries on server side (using Go tip):

2016/01/12 22:46:25 http2: server: error reading preface from client 127.0.0.1:42448: read tcp 127.0.0.1:8443->127.0.0.1:42448: read: connection reset by peer

2016/01/12 22:55:04 http2: server: error reading preface from client 127.0.0.1:42534: remote error: bad certificate

2016/01/12 22:55:04 http: TLS handshake error from 127.0.0.1:42538: remote error: bad certificate

(the first when using Chrome, the second and third when using Firefox)

Does that mean that a client can kind of "intentionally write logs" when he reports to the go server that he does not trust a certificate? Could this be kind of a "security problem"? Or is it a feature? ;-) Is there any way to change log verbosity or to disable these log entries in http and http2?

[hartwig]

To be a little bit more clear:

I wonder whether it should be considered a security bug, that an attacker can intentionally and foreseseeable write X bytes (length of the above log lines) to any go webserver's log/disk by starting a https connection and then reporting back that he does not trust the certificate.

I don"t have any security skills, so I'm asking just out of curiosity...?

[Konstantin Khomoutov]

On Tue, 12 Jan 2016 14:48:11 -0800 (PST)
hartwig <hartwig...@gmail.com> wrote:

> when serving an untrusted / wrong hostname tls certificate from go
> server, I get the following log entries on server side (using Go tip):

[...]

Uh, what is "go server"?

[hartwig]

Sorry, HTTPS server from the go standard library

[James Bardin]

On Wednesday, January 13, 2016 at 9:09:58 AM UTC-5, hartwig wrote:

To be a little bit more clear:

I wonder whether it should be considered a security bug, that an attacker can intentionally and foreseseeable write X bytes (length of the above log lines) to any go webserver's log/disk by starting a https connection and then reporting back that he does not trust the certificate.

What string exactly is the client writing here? (and note that a similar situation occurs for most http server, which usually write the requested path to the logs). 

[hartwig]

The strings written are the log lines regarding handshake error / remote: bad certificate and in the case of http/2 the preface reading error.

The difference to access log writing is that it is up to the server whether he wants to write access logs. If he decides to write access logs or any other log messages known to be directly triggered by client behavior, the server will - or should be - prepared to handle this in a safe manner, i.e. by taking care of log roatation etc.

However, in the case mentioned here, the logging comes "automatically" from the standard lib and I don"t think that any user of http or http/2 is prepared to handle logfile writes possibly triggered directly by client behaviour.

[James Bardin]

On Wednesday, January 13, 2016 at 9:51:26 AM UTC-5, hartwig wrote:

The strings written are the log lines regarding handshake error / remote: bad certificate and in the case of http/2 the preface reading error.

This isn't from the client, it's from the http server (crypto/tls package). It's part of the TLS protocol, and is in response to a TLS alert for "bad_certificate" (alertBadCertificate in tls/alert.go). The only thing the client is sending is the number 42. 

https://tools.ietf.org/html/rfc5246#section-7.2

 

[hartwig]

I do understand that the log lines are from the server. However, they are triggered by the client sending back the bad_certificate alert. It is completely up to the client whether he trusts your certificate or not. So, an attacker could repeatedly connect and send back number 42 for "bad certificate". He could do so whatever certificate the server would present to him. In the case of doing this with a server known to be implemented by the Go std lib, he would know that every time he does so will trigger these log messages and therefore possibly disk writes on the server side. This could be used for intentional log pollution, disk filling, log rotation triggering etc...

That"s why I think, that http and http2 should handle this case "silently".

[James Bardin]

On Wednesday, January 13, 2016 at 10:07:19 AM UTC-5, hartwig wrote:

I do understand that the log lines are from the server. However, they are triggered by the client sending back the bad_certificate alert. It is completely up to the client whether he trusts your certificate or not. So, an attacker could repeatedly connect and send back number 42 for "bad certificate". He could do so whatever certificate the server would present to him. In the case of doing this with a server known to be implemented by the Go std lib, he would know that every time he does so will trigger these log messages and therefore possibly disk writes on the server side. This could be used for intentional log pollution, disk filling, log rotation triggering etc...

That"s why I think, that http and http2 should handle this case "silently".

What if *I* need to log TLS alert responses?  

There's nothing in the library directly writing to a log file by default, and there's actually nothing writing these errors out by default at all. You have to explicitly choose how and where to write the logs.  (It's a little unfortunate that ErrorLog/log.Logger isn't an interface, but it's still workable). 

The "net/http" package isn't a fully configured server, it's a library with which to work. It's up to the programmer to make certain the system is hardened against any number of resource-exhaustion/DOS attack vectors, which can impact you far more quickly than logging errors. 

[hartwig]

If *you* want to log TLS alert responses, you could do so by using your custom configured tls listener that reports TLS alerts received by the client and provide that to a net/http server :-).

I think the net/http package should not report TLS alerts by the client by default. I would assume that net/http logs errors that are probably related to server side bugs/errors/malfunctions or connection errors. A message received by the client that *HE* decided to not trust your certificate should not be assumed to be such an error, because the decision is completely up to the client. Therefore, the fact that the client sends back such a response doesn"t seem to be a good indicator for an "error"?

However, I see that the attack surface would be VERY small and you would have to do MANY requests to trouble the server. :-)

I was just curious, whether anybody else thinks, that net/http's / net/http2's default behaviour to log those TLS-alerts could be "wrong" or problematic. :-)

[Brad Fitzpatrick]

You can set your net/http.Server's ErrorLog (https://golang.org/pkg/net/http/#Server) and filter out things you don't care about.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hartwig]

Great! Thanks Brad, didn't notice that field until now... :-)

Would love to here your opinion on whether net/http.Server should log those go-aways from clients claiming not to trust a certificate... :-)

[Brad Fitzpatrick]

On Wed, Jan 13, 2016 at 11:20 AM, hartwig <hartwig...@gmail.com> wrote:

Great! Thanks Brad, didn't notice that field until now... :-)

Would love to here your opinion on whether net/http.Server should log those go-aways from clients claiming not to trust a certificate... :-)

I think it's a pretty useful error message. If one installs a new TLS certificate and starts seeing tons of clients not liking it, that's a pretty good signal that the TLS cert isn't good (e.g. forgetting to concatenate intermediate certs)