TLS InsecureSkipVerify

[driskell]

TLS InsecureSkipVerify

[driskell]

Hi

Is this with Go 1.2? It will report that when the certificate name does not match the name used to connect from courier's config.

Your workaround will disable certificate checks. Ok for testing but not live.

Jason

[cova-fe]

I'm using it with Go 1.3, actually (I had installed that version on my test machine), but I think that the behaviour is the same as Go 1.2 in this respect.
Many thanks for your answer. Maybe a switch on configuration file that allows to disable TLS could be useful for testing, but I can live with the actual behaviour :)

[driskell]

Aha! Did you bypass the makefile to build it? The stable version won't build with 1.3 - makefile checks the version and rejects.

It will work in 1.2 I think. This is a breaking change in Go 1.3 to increase TLS security. Before it would bypass validation of common name if you don't specify server name in code. Whereas now it forces validation even if you don't provide name in code. I have a branch that fixes this - it provides the given "servers" item to TLS as server name so it can verify. Downside is this change means even in 1.2 it needs server names to match (where before it would not.) So its breaking change here too.

Thus, I'll be adding some useful openssl scripts to generate certificate pairs soon that correctly have the matching server names etc. At which point I'll be merging in the Go 1.3 support too so things don't get confusing.

Regards,

Jason

[driskell]

I have contemplated having a TCP transport mode (with no TLS layer on top) - but not had a personal use for it. If it's a desirable option I will definitely look at it again.

[cova-fe]

Well, I have added a "3" in the right place on Makefile :) besides that it works. (let alone issue #4 , but I think it's not related to go version). I have a use case for no TLS (internal servers on the same network sendings a bunch of no sensitive logs)... but of course I have several use cases also for TLS :)

[driskell]

Heh OK. Hopefully I can get the Go 1.3 merged in soon with the scripts, then things should work OK.

I'll definitely consider a TCP only version. Thinking about it, for an internal network with high log volume it could be useful as will reduce resource usage even more.

[driskell]

I just want to add for reference. That when using IP addresses in the servers configuration, validation will fail even if the certificate common name is the IP.

The validation is strict in that IP will only validate if the certificate has that IP in the SAN list. The documentation I did for generating self signed SSL refers to this. Just need to edit the openssl.cnf to add the IP then "make selfsigned" will add it. I'll eventually move this to a tool/script away from make but it was easiest way for now.

[shurane]

@driskell, I run Logstash and Elasticsearch on AWS EC2 instances, and sometimes I do something like the following:

$ fab logstash-server ip
11.22.33.44
$ fab logstash-server kill
$ fab logstash-server new
$ fab logstash-server ip
55.66.77.88

When I bring the EC2 instance with the logstash server down and then back up, it gets assigned a different IP. I then deploy this IP address to the nodes that run logstash-forwarder and log-courier. In this case, it seems like I would need to make a new set of certificates every time.

It looks like my options are:

1. Ignore the IP SANs stuff with TLS.
2. DNS so I can always point to logstash.mydomain.com.
3. Regenerate new SSL certificates with make selfsigned and deploy them to the machines.

Is there a reason I don't want #1? I know this is how logstash-forwarder operates, as it doesn't complain with cannot validate certificate for vv.xx.yy.zz because it doesn't contain any IP SANs and just keeps on chugging along. I have an idea of what the security risks are as well (any server that happens to contain my SSL certs can pretend to receive and send data).