I was wondering if it is needed the SHA-256 algorithm to generate a certificate request for configuring SSL in node-red or if another algorithm could be used. I have looked in the node.js library and I don't find any information about this.
Do you know about this?
There is no special algorithm needed, you can load any (valid or self-signed) SSL certificate to node-red.
That said, if you need a valid SSL cert for a node-red instance, this is one (simple) option you can evaluate: link
Related
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 have been a long time reader but this is my first real post on a topic that I couldn't find a solution to.
I am currently hosting a website on Windows 2012 that I would like to get the latest TLS 1.2 ciphersuites running on.
I am aware of how to enable TLS 1.1 and TLS 1.2 in windows and have done so(via registry edits). I have also changed the cipher order to what I would like it to be.
My question is: How do i actually go through and set up my ECDHE / ECDSA portion of the cipher suite after this step?
When i view the site in the latest chrome beta (which supports ECDHE and ECDSA in TLS 1.2 provided you use the supported curves) it seems to skip all of the ECHDE ciphersuites.
Is there something else i need to do to get ECDHE/ECDSA properly enabled?
I have read around on the net trying to solve this myself and they mention making copies of your root cert and then modifying them to somehow support ECDHE. Am i barking up the wrong tree?
Thank you in advance for any and all support with this issue.
Edit: adding clarification/progress
After more research, I have found that in order to get ECDSA to work, you need an ECDSA certificate. The only way to get one at this time is to self-sign, as the cert-cartel has not yet come up with proper cross-licensing agreements and fee structures for Ellipic Curve Certificates yet.
Since self-signing is not an option for this site, I have removed all ECDSA suites from the cipher-order.
Unfortunately, because all of the AES Galois Counter Mode suites were also ECDSA, this rules those out for the time being.
This leaves me with a strongest cipher suite of ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521 which I BELIEVE is supported by the latest version of Chrome beta correct? I can't seem to get Chrome to pick up anything beyond SHA-1. Is there no SHA-2 support? even in the latest beta?
AES-GCM is about how you encrypt the data in your connexion, EC-DSA or RSA about how the server identifies itself to the client. There is therefore no reason why you couldn't do AES-GCM encryption with a RSA authentication.
RFC 5289 does define the needed suite for that :
https://www.rfc-editor.org/rfc/rfc5289#section-3.2
CipherSuite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 = {0xC0,0x2F};
CipherSuite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 = {0xC0,0x30};
CipherSuite TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 = {0xC0,0x31};
CipherSuite TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 = {0xC0,0x32};
It's not however necessarily easy to find both the client and the server that will support them.
I had similar experiences with Win2008 R2.
Depending on the certificate, GCM cipher is offered by the server or not.
With self-signed ECDSA certificate i got GCM to work but older browsers
or Windows XP can't connect to such a https-site.
Windows doesnt support any TLS_ECDHE_RSA...GCM... ciphers:
http://msdn.microsoft.com/en-us/library/aa374757(v=vs.85).aspx
Thus normal RSA-certificates don't work with GCM under Windows.
Browser compatibility:
http://www.g-sec.lu/sslharden/SSL_comp_report2011.pdf
I'm using SSL to form a trusted connection between two peers. Each peer knows who it expects to be connecting to (or accepting a connection from) at a given time. It should only accept valid certificates, and further, it should only accept certificates with certain attributes (probably by checking the canonical name).
So far, I can get the two sides to talk, based on the example in this question, and its answer. Each side can print out the certificate presented by the other peer.
I'm not sure what the correct way to verify these certificates is, though. The obvious way would be to just look at the certificates after the connection is made and drop the connection if it doesn't meet our expectations.
Is there a more correct way to do this? Is there a callback which is given the peer's presented certificate and can give it a thumbs-up or thumbs-down? Or is the right thing to handle it after SSL is done with its work?
In this case, I am the CA, so trusting the CA isn't an issue. I'm
signing these certificates on behalf of my users. The canonical names
aren't even domain names. Users connect peer-to-peer. I want the
client software I distribute to verify that the connecting user has a
certificate I signed and is the right user.
Its sounds like you are running a Private PKI. Just load the root of the trust chain into OpenSSL with SSL_CTX_load_verify_locations or SSL_load_verify_locations.
Be sure to use SSL_PEER_VERIFY to ensure OpenSSL performs the verification. The call would probably look like SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, NULL);. If peer validation fails, then the connect will fail.
There are ways to ensure the connect succeeds and then catching the error later. The trick is to set the verify callback, have the verify callback always return 1, and then call SSL_get_verify_result after the connection is setup. See SSL/TLS Client for an example.
Note: in all cases, you still have to perform name checking manually. OpenSSL currently does not do it (its in HEAD for OpenSSL 1.1.0). See libcurl or PostgreSQL for some code you can rip.
An example of a SSL/TLS client is provided by OpenSSL at its wiki. See SSL/TLS Client. There's no server code or example at the moment.
I'm not sure what the correct way to verify these certificates is, though.
The obvious way would be to just look at the certificates after the
connection is made and drop the connection if it doesn't meet our
expectations.
There's a lot to this, and some of it is not obvious. I'm going to break the answer up into parts, but all the parts try to answer your question.
First, you can verify the certificates are well formed. The group responsible in the context of the Web is the CA/Browser forums. They have baseline and extended requirements for creating certificates:
Baseline Certificate Requirements, https://www.cabforum.org/Baseline_Requirements_V1_1_6.pdf
Extended Validation Certificate Requirements, https://www.cabforum.org/Guidelines_v1_4_3.pdf
In the baseline docs, you will find, for example, an IP listed as the Common Name (CN) must also be listed in the Subject Alternate Names (SAN). In the extended docs, you will find that private IPs (Reserved per RFC 1918) cannot be present in a extended validation (EV) certificate; and EV certificates cannot contain wild cards.
Second, you can perform customary validation according to RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, http://www.ietf.org/rfc/rfc5280.txt.
The customary checks are the ones like hostname matching, time period validity checks, and verifying an end-entity or leaf certificate (client or server certificate) chains back to a root. In browsers using CAs, that's any number of hundreds of trusted roots or intermediates.
If you choose to perform revocation checking, then you will probably DoS your application (how is that for obvious!). A mobile client on a 3G network cannot download and process a 30MB CRL - it will surely hang the application. And an application cannot perform a OCSP query when the URL is wrong - that will surely fail.
Also, if you are performing hostname matching that includes wildcards, then care must be taken to handle ccTLDs properly. ccTLDs are like *.eu, *.us, or இலங்கை (nic.lk). There's some 5000 or so of them and Mozilla offers a list at http://publicsuffix.org/ (alternately, https://mxr.mozilla.org/mozilla-central/source/netwerk/dns/effective_tld_names.dat?raw=1).
Third, CAs don't warrant anything, so the answers you get from a CA is worthless. If you don't believe me, then check their Certification Practice Statement (CPS). For example, here is an excerpt from Apple's Certification Authority Certification Practice Statement (18 Sept 2013, page 6):
2.4.1. Warranties to Subscribers
The AAI Sub-CA does not warrant the use of any Certificate to any Subscriber.
2.4.2. CA disclaimers of warranties
To the extent permitted by applicable law, Subscriber agreements, if applicable,
disclaim warranties from Apple, including any warranty of merchantability or
fitness for a particular purpose
That means that they don't warrant the binding of the public key to the organization through the issuer's signature. And that's the whole purpose of X509!.
Fourth, DNS does not provide authentic answers. So you might get a bad answer from DNS and happily march over to a server controlled by your adversary. Or, 10 of the 13 root DNS servers under US control may collude to give you a wrong answer in the name of US national security.
Trying to get an authentic response from a non-US server is near impossible. The "secure DNS" pieces (sans DNSSEC) are still evolving, and I'm not aware of any mainstream implementations.
In the case of colluding US servers, a quorum won't work because the US holds an overwhelming majority.
The problem here is that you are making security decisions based on input from external services (CA and DNS). Essentially, you are conferring too must trust in untrustworthy actors.
A great treatment of the problems with PKI and PKIX is Dr. Peter Gutmann's Engineering Security at www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf. Be sure to read Chapters 1 adn 6. Dr. Gutmann has a witty sense of humor, so its not dry reading. Another great book is Ross Anderson's Security Engineering at http://www.cl.cam.ac.uk/~rja14/book.html.
You have a couple of defenses with all the problems caused by PKI, PKIX, and CAs. First, you can run a private PKI where you are your own certificate authority. In this case, you are not trusting an outsider. Bad DNS answers and rogue servers should be caught because the server's certificate will not form a valid chain.
Second, you can employ a security diversification strategy. Gutmann writes about it in his Engineering Security book, and you should visit "Security through Diversity" starting on page 292 and the "Risk Diversification for Internet Applications" section on page 296.
Third, you can employ a Trust-On-First-Use (TOFU) or Key Continuity strategy. This is similar to Wendlandt, Anderson and Perrig's Perspectives: Improving SSH-style Host Authentication with Multi-Path Probing or SSH's StrictHostKeyChecking option. In this strategy, you do the customary checks and then pin the certificate or public key. You can also ask for other's view of the certificate or public key. Unexpected certificate or key changes should set off alarm bells.
OWASP has an treatment of Certificate and Public Key Pinning at https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning. Note: some places rotate their certificates every 30 days or so, so you should probably pin public keys if possible. The list of frequent rotators includes Google, and its one of the reasons tools like Certificate Patrol makes so much noise.
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.
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"
*/