Good day!
I have difficulties with requests in Go. Locally service works fine, but in the server I have this error:
"Post "https://x.x.x.x:xxxx/": x509: cannot validate certificate for x.x.x.x because it doesn't contain any IP SANs
Solutions like using dns is not suite, only ip address with port, since it is an internal service.
Also, tried out:
TLSConfig: &tls.Config{
InsecureSkipVerify: true
}
Updated! Tried out with NodeJS, works fine, so I think problem with Go's tls configs
Please, hint me how can eliminate this error?
Related
If I'm making TLS requests to an API server that I'm referencing by IP, are the kinds of MITM attacks that certificate validation prevents still possible?
Background info if it clarifies the question: I'm making TLS requests to a REST API with a static IP that has no domain name associated with it. To make this work in Go, I have to set the InsecureSkipVerify: true, at the Transport layer of my HTTP Client. Does this make my requests less secure?
I would assume it does but I don't really know why.
As #James noted the IP is an irrelevant component of a TLS handshake.
While the standard procedure is:
dial hostname/port
DNS lookup hostname to get IP
TLS handshake w/ IP
reveals hostnames certificate identity
verify cert name matches hostname
Using InsecureSkipVerify: true skips the last step - and is generally only used during development/testing.
You can however use a different name, in this last step, for the certificate identity to match: leveraging the ServerName field in tls.Config:
tc = &tls.Config{
ServerName: "myhostname", // certificate identity
RootCAs: rootca,
// InsecureSkipVerify: true // <- avoid using this
}
d := tls.Dialer{
Config: tc
}
conn, err := d.Dial("tcp", "127.0.0.1:8080")
Here we are dialing an IP address, performing a TLS handshake, but instead of the default behavior of comparing the host cert with 127.0.0.1, it will instead verify it matches myhostname.
I'm trying to run the buildlet at https://github.com/golang/build/tree/master/cmd/coordinator
There is a locally hosted server connection that keeps failing to connect giving the error:
first record does not look like a TLS handshake
The piece of code that fails is from build/cmd/buildlet/reverse.go and it is:
tcpConn.SetDeadline(time.Now().Add(30 * time.Second))
config := &tls.Config{
ServerName: serverName,
InsecureSkipVerify: devMode,
}
conn := tls.Client(tcpConn, config)
if err := conn.Handshake(); err != nil {
return nil, fmt.Errorf("failed to handshake with coordinator: %v", err)
}
I've gathered that the connection should be established while ignoring TLS issues because the server is at localhost
I can't seem to figure out how to fix this issue.
Instructions on recreating my problem are at the above link. The only change I recommend is using
go run . -mode=dev -listen-http=localhost:8119
for the first command
InsecureSkipVerify just means that TLS certificate validation constraints are relaxed (to a point where your connection is insecure and prone to MITM attacks)
From the documentation:
If InsecureSkipVerify is true, crypto/tls accepts any certificate presented by the server and any host name in that certificate.
You still need to have a connection that uses TLS at the other end. The error that you're getting means that the other side of the connect doesn't speak TLS.
If you don't want to use TLS in devMode, then you should use the tcpConn directly while in dev mode, without wrapping it with a *tls.Conn. *tls.Conn implements net.Conn so after the handshake there shouldn't be any difference in how you use the connection, whether it has TLS or not.
I am running a HTTPS server in Linux (RHEL 7). I am getting the below error as soon as I start the server.
2019/09/04 15:46:16 http: TLS handshake error from xx.xx.xx.xx:60206: EOF
2019/09/04 15:46:21 http: TLS handshake error from xx.xx.xx.xx:31824: EOF
This error is coming automatically and continuously in the terminal.
Below is the go code for creating https server -
package main
import (
"fmt"
"net/http"
"github.com/gin-gonic/gin"
)
func main() {
fmt.Println("Starting webserver")
router := gin.Default()
router.GET("/", func(c *gin.Context) {
c.JSON(http.StatusOK, gin.H{
"success": true,
})
})
router.RunTLS(":9001", "server.pem", "server.key")
}
We have purchased and combined the server certificate, intermidate certificate and root certificate into a single file to make the server.pem file.
As this error is coming continuously and in the terminal as soon as I start the server, I think there is some configuration problem in the VM?
Please suggest what are the things I can check here.
NOTE: This error is specific to the Go. I have tested on the same server on the same port with same certificates in Node JS. And it works fine.
Also the IP in the error message is of the reverse proxy server (WAF) which is continuosly doing health monitoring of the web application server.
I would attack the problem from two angles:
What is this xx.xx.xx.xx address? I'd expect that when I start some random piece of software, there is nothing to connect to it all by itself, right?
Is there anything special about that 9001 port? Try running nc -l -p 9001 and see whether those unidentified connections happen as well.
Run tcpdump and see whether there is any incoming traffic from the clients making those connections: those EOFs (that's "end of file") reported by the TLS mchinery most probably mean those clients—whatever they are—close their side of the connection somewhere amidst the TLS handshake—while the server is expecting to read some data from them.
This hints at that those clients do not actually expect to see TLS protocol in the connection they open; and they pretty much may send some plaintext in it, so you'll be able to peek at it.
Googling for "9001 port" hints at that it's used for some "ETL service manager" protocol—whatever it is. This hints at that traffic on 9001 might be related to VoIP.
I have no idea what to do with this, but it might give you some lead for further research.
Issue "Curl::Err::SSLConnectError"
Can any one tell me what will be the exact URL for Payflowpro now ,
the Url "https://payflowpro.paypal.com" does not work for me now.
It was working fine before but for some reason it gives me an error now.
Code in Lib file
Code in module
post_contents = Curl::PostField.content('TRXTYPE', 'S'),
Curl::PostField.content('TENDER', 'C'),
Curl::PostField.content('AMT', amount),
Curl::PostField.content('ORDERID', order),
Curl::PostField.content('CURRENCY', PAYPAL_CONFIG[:currency]),
Curl::PostField.content('CREATESECURETOKEN', 'Y'),
Curl::PostField.content('SECURETOKENID', secure_random),
Curl::PostField.content('PARTNER', PAYPAL_CONFIG[:partner]),
Curl::PostField.content('VENDOR', 'abababa'),
Curl::PostField.content('USER', 'abababa'),
Curl::PostField.content('PWD', 'abababa')
Logs Details
Started POST "/__better_errors/45429440/variables" for 127.0.0.1 at 2015-01-20 12:24:16 +0500
TRXTYPE=S
TENDER=C
AMT=5.99
ORDERID=1421738848U1
CURRENCY=USD
CREATESECURETOKEN=Y
SECURETOKENID=****
PARTNER=Paypal
VENDOR=****
USER=*****
PWD=*****
Rebuilt URL to: https://payflowpro.paypal.com/
Hostname was NOT found in DNS cache
Trying 173.0.82.162...
Connected to payflowpro.paypal.com (173.0.82.162) port 443 (#2)
successfully set certificate verify locations:
CAfile: none
CApath: /etc/ssl/certs
error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
Closing connection 2
The reason for this is the change announced by PayPal.
Whoever is using the older SSLv3 needs to check their implementation of update their code to use the TLS version for curl.
PayPal provides info in this link.
That is still the correct endpoint. It looks like something going on with your DNS based on the message stating "NOT found in DNS cache."
You could try changing to use different DNS servers and see if that resolves your issue. For example, you could use Google's DNS servers or OpenDNS.
Google's DNS servers are 8.8.8.8 and 8.8.4.4.
Open DNS is 208.67.222.222 and 208.67.220.220.
Depending on your router you may be able to update the DNS server there, or you may need to do it from your local NIC card properties.
I'm writing a Go package for the Google TV Pairing Protocol. But I seem to be hitting a problem with the TLS handshake.
sock, err := tls.Dial("tcp", "10.8.0.1:9552", &tls.Config{InsecureSkipVerify: true})
That line gives me a handshake error. The exact error message is: remote error: handshake failure. If I try the same host/port via curl, it gives curl: (35) error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure as well.
Any ideas? Is the Google TV expecting a client cert maybe? I haven't seen any references to the need for a client cert anywhere.
If anyone wants to help figure it out, here's the code:
https://github.com/dustywilson/go-polo
The README file has the easy code to check it out. You will have to know the IP address for your Google TV box since this doesn't use mDNS. If you (someone, anyone) run this and you get different results, let me know.
I've already gone through the Google TV Remote code at google-tv-remote. A more useful one is google-tv-pairing-protocol which is the equivalent Java/Android project to what I'm doing. Of course I've already poured over that code. I think it's a problem either with Go itself (unlikely), a problem with the Go TLS package not knowing how to read the Google TV's certificate (I know it was a problem a year ago), or a problem with my code (typically would be most likely, but I'm just not seeing it).
By the way, I'm testing this on a Logitech Revue and it has a self-signed SSL certificate. It's not rooted or modified in any way.
My resulting code will be open source, of course. Thanks for the assistance.
Client certs are generated by the Java remote client at runtime, and stored for future use. Check out the code at:
http://code.google.com/p/google-tv-remote/source/browse/src/com/google/android/apps/tvremote/KeyStoreManager.java
You might be running into an invalid cert. According to the code, you need a specific CN.
/* Returns the name that should be used in a new certificate.
* The format is: "CN=anymote/PRODUCT/DEVICE/MODEL/unique identifier"
*/