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"
*/
Related
I'm using Google's simplehttp2server go-lang program to run some tests and have encountered a recurring error. Upon executing the TLS handshake I receive the following error:
2019/12/12 12:42:55 http: TLS handshake error from 127.0.0.1:36202: read tcp 127.0.0.1:5000->127.0.0.1:36202: use of closed network connection
I have updated my go version to 1.13.5 from 1.12.9 and tried two browsers (brave + chrome) plus curl and receive the same error code each time. It happens over HTTP/2 and HTTP/1.1. I have seem other answers from across the web but am still running into this error (ex1, ex2, ex3, ex4).
Very much appreciate any feedback, advice, or admonishment. Anything to help the migraine this problem is giving me!
edit: screenshot from my curl and running of simplehttp2server
example image from curl and simplehttp2server
This error happens when you have two websockets connected to a singular address using the same port from the same machine. One of the websockets will be able to connect fine but the other wont be able to make the connection.
I was making the same mistake and when I removed the duplicate connection the error resolved.
My app was rejected today due to 'not supporting IPv6'. I've attached screenshots of the error they received which comes from a Parse.com API call.
I could really use some help on this, as I have no clue where to start with this.
Does anyone know if Parse.com supports IPv6? Or do I need to add something to my code? Do I need to migrate to Parse Server?
Please help =\
---- EDIT ---- 9/22/16
OK so, after my first rejection due to "IPv6" issues, I re-submitted and the app was approved. I'd still like to understand if Parse.com and Parse Server are officially IPv6 compatible but as for now, I'm just happy my app was approved. I'll keep this thread open and will edit it when I find the answer.
I have a parse server hosted on Heroku which doesn't support IPv6 yet (see here). But your server is not the reason why the app is rejected. It is your app which should support IPv6.
A possible solution is to download the latest Parse framework from https://github.com/ParsePlatform/Parse-SDK-iOS-OSX/releases/tag/1.14.2 and replace the old ones. I think it should work.
Below is my comparison with the logs in the console for my app with the two different versions of Parse framework.
I have used Parse.framework and Bolts.framework from Feb 2016 in my Apple TV app and also just got rejected also for not supporting IPv6. I checked the log and found that
nw_resolver_start_crazy_eyeballs_timer Received IPv4 result first, performing crazy eyeballs: waiting 50ms on IPv6 for myapp.herokuapp.com:0.
__nw_resolver_start_crazy_eyeballs_timer_block_invoke Crazy eyeballs timer fired: did not receive IPv6 in time, reporting only IPv4 result for myapp.herokuapp.com:0
nw_resolver_cancel_crazy_eyeballs_timer Cancelling crazy eyeballs timer for myapp.herokuapp.com".
It seems the performance issue comes from the 50ms when the app loads.
I use the latest Parse framework and no "crazy_eyeballs_timer" shows up. The log seems more promising because I can see a IPv6 address in the log now.
nw_resolver_create_dns_service_on_queue Starting host resolution myapp.herokuapp.com:0, flags 0x4000d000
nw_resolver_host_resolve_callback flags=0x3 ifindex=0 error=NoSuchRecord(-65554) hostname=myapp.herokuapp.com. addr=0.0.0.0:0 ttl=60
nw_resolver_host_resolve_callback flags=0x2 ifindex=0 error=NoError(0) hostname=us-east-1-a.route.herokuapp.com. addr=88:ffff::bbbb:afb9.0 ttl=74
Here I changed the addr of my server in the log for security reason.
I will send a new update of my app to review and I believe that it should work. I will leave a comment when it gets accepted :)
SSL_connect returned=1 errno=0 state=SSLv2/v3 read server hello A: sslv3 alert handshake failure (OpenSSL::SSL::SSLError)
This error is a pretty common one to anyone using ruby on windows.
For me, the solution has always been this. It has worked great on any computer I have put it on and I've loved it.
Just this week it stopped working. Has anyone else had this happen?
I've tried getting the cert from curl again just in case the cert was no longer valid. I tried removing and adding the environmental I use mechanize and tried to reference it as suggested here.
I've also tried going to different urls, "https://google.com" and others, for example.
Nothing so far. Anyone have a better solution for this? It has happened on all windows computers that I have this cert referenced this way.
Your problem seems to be different to the one you linked to. There it failed to verify the certificate returned by the server. Here it erros earlier when it reads the server hello. Do you have any more debug information eg stacktrace or a pcap of the interaction?
A (highly) speculative explanation is that you sent an sslv2 compatible client hello and the server returned an ssl alert as it will only accept sslv3/tls format client hello
I'm getting bit helpless with this.
I need a tool that can perform MITM on any chosen SSL stream from localhost to remotehost (not just HTTPS!). Searching for such application seems to be pretty difficult task because all apps seems to follow this trend: SSL==HTTPS. My application trusts the certificate so that's not an issue. For HTTPS I use Proxifier + Charles Debugging Proxy. However Charles can capture only HTTPS, not binary SSL crypted data.
How do I imagine the flow of data.
In best case:
Application->MITM_PROXY->Server
Or:
Application->Proxifier->MITM_PROXY->Server
I think only one working so far was this combination:
SSLSplit on virtualized Linux + virtualized Windows with the application and default gateway set to that linux. Which is as you can imagine very inconvenient. Also the SSLSplit logs both recv and send into one file, which can be problematic with binary stream (I could deal with it I guess).
Any advices?
You could also use sslsplit -L to log to a single log file or named pipe and use a simple script to parse the log format used by SSLsplit, extracting the binary payload and do whatever you like with it. -L uses log headers for each logged segment. SSLsplit comes with a simple python module for parsing its log files in extra/logreader.py.
I know its a rather old question (4 months), but as it still has not been answered i'll give it a shot and leave a direction for future searches.
Have you tried Cain&Abel or stunnel?
I would like have one quick question. Is there any addon for Firefox or tool how to get session key generated from master secret during SSL handshake by which is encoded symmetrically whole client/server communication? I need it due to decoding of communication (POST/GET/etc..) via Wireshark or PCAP library. As I can see Firebug is showing decrypted communication so I hope there exist some proper ways how to reach this session key :)
Thank you all for a help.
I have good news for you. You can actually get the Master-Key data that you need from both Firefox and Chrome. And you can use the output file in Wireshark to decrypt the SSL/TLS traffic without the need for the private key from the SSL/TLS server. Check out "Method 2" here: http://www.root9.net/2012/11/ssl-decryption-with-wireshark-private.html
As a tip, if you don't want to reboot your machine just open a command prompt and run:
set SSLKEYLOGFILE=c:\sslKeyLogFile.txt
"C:\Program Files (x86)\Mozilla Firefox\firefox.exe"
Since Firefox is being launched from the same session that you added the environment variable in, it will launch with that variable set. Otherwise a restart of Windows will be required after setting it in the System settings dialogs.
I also want to point out that the answer from Chris wasn't necessarily wrong, this is a fairly new feature. It didn't make it into release until Wireshark 1.6.
If you want to use Wireshark then the pre master secret will be of no use for you (you refer to it as 'cipher key' in your question).
Wireshark can only decrypt traffic if you specify the RSA private key of the server, which doesn't change on every connection unlike the pre master secret. However, you can't get that through your browser or anything else for obvious reasons.
If you want to decrypt SSL traffic I suggest using an intermediate proxy instead, like Fiddler. It does not passively capture traffic but proxies the traffic, which enables it to actually decrypt the data sent and received.