It's slightly embarrassing to ask this, but here it goes: What's the difference between generating public/private keys via ssh-keygen and cfssl?
I've successfully used ssh-keygen to create pub/private key credentials that can be used to ssh into a server. I've also successfully used cfssl to create a private key & certificate for a web site. However, I can't seem to figure out how to use cfssl to do what ssh-keygen does.
Since they both can be used to generate public/private RSA 4096 keys, it seems as if they could be used interchangeably. Unfortunately, no matter how many different combinations I try, or how much I search the interwebs, I can't seem to find a working example.
I'm starting to think that there's something I fundamentally don't understand regarding each tool's approach to encryption.
People of stackoverflow land... have mercy on me, and please point out the error of my ways. Your help is truly appreciated.
No, these two types of keys aren't interchangeable. RSA is an algorithm for encryption and digital signatures. It is used in both TLS (for web sites) and SSH, but those two protocols, while they both support RSA keys, use the algorithm differently.
A protocol specifies a (hopefully secure) technique for using standard algorithms and protecting data with it, and there are many secure ways to use RSA to sign data, which differ based on the protocol. Similarly, both TLS and SSH can use AES-GCM to encrypt and authenticate data, but they will use it differently.
Moreover, even if you could generate keys for one with the other, you generally don't want to reuse keys for different purposes. That's because in some cases, an attacker can capture a valid message in one protocol and use it in the other protocol to impersonate the legitimate party.
Do note that the private key formats typically used by OpenSSH and TLS implementations are often the same, but the public key formats are not. An SSH public key is going to look totally different than an X.509 public key used with TLS.
If you need to create keys for use with SSH, you should use ssh-keygen, and if you need to create a key for use with your web server or another TLS server, use a tool for that, like openssl or cfssl.
Related
Problem:
I'm pretty new to this TLS thing and networking in general. But i'm trying to passively listen and decode TLS packets. I find it kind of frustrating that i cant decode packets on my network on my computer. The conclusion i got to is that is impossible because how TLS works. But in mathematics if you have enough of information you can often get the value of the unknown. In this instance i guess it might be the servers key that is the missing link.
Even if it would be cool to totally decrypt packets its not my main goal. What i specifically trying to do is to know if a specific twitch stream is watched on my computer/network. So if i type in the streamers name in to the program it checks if that stream is sent to my computer and responds with a boolean.
So i want your input guys and girls. Is there any way of achieve this without doing Man in the middle?
Thoughts:
I have been thinking about this problem and i got a couple of ideas (don't laugh at the possible stupidity, I'm not always very smart but its just some things that came to my mind):
(Comparing) Using my cert to send request to the twitch api and somehow compare the response and see if they have the same encrypted payload. Then i know this specific stream is watched.
(Decoding) feed cert (public and private key), decrypted message and encrypted message to some algorithm to get server key. My theory here is that i have enough information to get the server key. But my knowledge about ssl is limited and i have not considered handshakes and such.
(Decoding) Generate training data to an ai to teach it to decode ssl packets. Generating a lot of ssl packets with different keys and feed the cert and encrypted data to the ai.
I hope you understand what I'm trying to do. English is not my native language (sorry).
(Comparing) Using my cert to send request to the twitch api and somehow compare the response and see if they have the same encrypted payload. Then i know this specific stream is watched.
Data are encrypted with a symmetric key specific for this SSL/TLS session. Also a random initialization vector is used. Thus, even transfer of exactly the same data results in different encrypted data which means no comparison of the encrypted data will help.
(Decoding) feed cert (public and private key), decrypted message and encrypted message to some algorithm to get server key. My theory here is that i have enough information to get the server key. But my knowledge about ssl is limited and i have not considered handshakes and such.
If (the obsolete) RSA key exchange is used you would need to have the servers private key to decrypt which you don't have. With Diffie-Hellman key exchange even this private key would not be sufficient, but you need to have the master secret or pre-master secret of this specific SSL/TLS session (see the TLS standards for details what this is). This secret can only be found in the TLS client and TLS server for the time the TLS session is active - which means that you will not be able to use this either for decryption unless you have access to the internals of the client, in which case you might just look directly which stream they are viewing.
(Decoding) Generate training data to an ai to teach it to decode ssl packets. Generating a lot of ssl packets with different keys and feed the cert and encrypted data to the ai.
Properly encrypted data are more or less random and have no inherent structure which can be mapped to the original data or even parts of the data. AI will not magically find such a structure too. The only possible difference it might use to distinguish streams are the size and timing of the data - but only if these are specific for a stream which I doubt. So, most likely it is impossible this way too.
I find it kind of frustrating that i cant decode packets on my network on my computer. The conclusion i got to is that is impossible because how TLS works.
Indeed this is primary purpose of TLS. If correctly implemented you should have no way of decrypting transfered data.
There are even buggy and obsolete implementation on some servers where one can exploit some vulnerabilities, but - not for Twitch and not with your knowledge level only for buggy implementation
Generally you could consider TLS secure enough to ensure traffic integrity and confidentiality.
What i specifically trying to do is to know if a specific twitch stream is watched on my computer/network.
I'd provide some options to achieve the goal, however that would introduce dangerous vulnerabilities into your computer or network. (you have been warned)
Still you can sniff out the unencrypted traffic. So you can see e. g. DNS requests (you could see what hostnames are resolved, but not specific URL).
For your computer you could install a keylogger or get the requested URL from browser before it is encrypted.
Integrity of TLS rely on certification authorities. In theory could can create your own CA certificate and make it trusted on your computer or network. That could allow you mounting a man-in-the-middle attack (posing yourself as the target server with your own keys).
I have a request to setup "mutual SSL Authentication" using SFTP. They want to have a ProFTPd SFTP server authenticate the client by certificate. Is this even possible using SFTP? I assume because SFTP is key based SSH rather than cert based, it is not easily done. I suspect what they really want would be FTPS but they insist SFTP. Is anyone doing anything like this? Thanks!
As already mentioned, the question does not make sense in several points:
SFTP is file transfer protocol over SSH, which does not support any "SSL authentication" (unless you use X.509 patch, thought it might be your target)
ProFTPd might support SFTP (not natively as mentioned in comments) and certainly not with different authentication than the one supported by SSH.
You can set up openssh with sftp-server and set up CA for signing host keys and client keys (not X.509, but openssh), which might suit your needs, except it is not "SSL".
Or the other way around, use ProFTPd, use real SSL, but give up SFTP in favour of FTPS.
Both solutions are valid and reasonable, but making some mutant between them does not seem like a good future-proof solution.
I don't really know much about IT and have been working in software development for 3 years. I have used version control with Github and Bitbucket, but I really don't know how SSH, SSL, HTTPS works. Can anyone explain them in the context of version control with a cloud service like Github? Why is TLS not used? A user case example would be most helpful. High-level is fine.
Firstly, while a number of people think SSH relies on SSL, it doesn't: it's an entirely different protocol. The fact OpenSSH relies on OpenSSL might be one of the causes of this confusion (whereas in fact OpenSSL can do much more than SSL).
Secondly, TLS is essentially a newer version of SSL, and HTTPS is HTTP over SSL/TLS. You can read more about this in "What's the difference between SSL, TLS, and HTTPS?" on Security.SE, for example.
One of the major differences (in the context of GitHub and Bitbucket) has to do with the authentication mechanisms. Technically, both password and public-key authentication can be used with or on top of SSL/TLS and SSH, but this is done rather differently. Existing libraries and tool support also matters.
GitHub (with Git) relies on an SSH public key for authentication (so that you don't have to store or use a password every time).
Public key authentication in SSH uses "bare keys", whereas you'd need a certificate for SSL/TLS (and in 99.9% cases that's going to be an X.509 certificate). (A certificate binds an identity to a public key by signing them together.) GitHub would have to use or set up a CA, or perhaps use various tricks to accept self-signed client certificates. All of this might be technically possible, but this would add to the learning curve (and may also be difficult to implement cleanly, especially if self-signed cert tricks were used).
At the moment, GitHub simply lets you register your SSH public key in your account and uses this for authentication. A number of developers (at least coming from the Git side) would have been familiar with SSH public keys anyway.
Historically, Git over SSH has always worked, whereas support for HTTP came later.
In contrast, Mercurial was mainly an HTTP-based protocol initially. Hence, it was more natural to use what's available on HTTPS (which would rule out using X.509 certificates if they're deemed too complicated). AFAIK, SSH access for Mercurial is also possible.
In both cases (Git and Hg), the SSH public key presented during the connection is what lets the system authenticate the user. On GitHub or Gitlab, you always connect as SSH user git, but which key you use is actually what determines the user in the system. (Same with Hg on Bitbucket: ssh://hg#bitbucket.org/....)
I doubt if it is a good question for StackOverflow, however.
All these protocols are used as (secured) channel for Git data exchange. And, when you see 'SSL' most likely SSL/TLS is meant - just to not type both abbreviations. TLS is a further development of SSL protocol.
I have a client application that runs on my computer, which uses openssl to communicate with server using SSLv3. I need to see what they talk so I basically want to edit and recompile openssl library in order to acquire relevant encryption keys.
The application usually uses TLS-DHE-RSA-WITH-AES-256-CBC-SHA as cipher suite. Sometimes it uses aes128 instead of aes256 but that's not critical at this stage. I edited s3_enc.c file so far. At the end of ssl3_setup_key_block function I write the master key, key block(so the client-server write keys, mac keys and IV's), server and client randoms to a file. http://www.ietf.org/rfc/rfc2246.txt says if the stream cipher is exportable, client-server write keys are to be updated as final client-server write keys accordingly. I'm not sure if this cipher suite is considered exportable(whatever that means), but I create final write keys anyway.
The problem is whatever I tried, I couldn't successfully decrypt any packet which I acquired using wireshark. The output is meaningless no matter what and I'm stuck. I am considering checking the mac fields of packets after decryption in order to see whether decryption was correct. But that also seems to be a dead end.
Does anyone have any idea what I am missing, what I might be doing wrong?
If you can modify OpenSSL and make your client application use it, then all you need to do is make your modified OpenSSL dump the decrypted data to the file. Even easier alternative would be to make OpenSSL use one of NULL ciphersuites even when the application requests certain encryption.
I need to send data from my iPhone application to my webserver, and back. To do this securely, I'm using an encryption algorithm. It requires a key that must be known by both the server and the user so that decryption can take place. I was thinking about just using a simple static string in my app and on the server as the key, but then I remembered that compiled code can still be disassembled and viewed, but only to a certain extent.
So, how safe would I be by placing the encryption methods and "secret" string in the source code of my app? Are there any other ways to accomplish communication between an app and server securely?
Thanks.
Yes, it can be found rather easily. Run the strings program on your executable and you'll probably find it. Besides, anything in your program can be "found", since it's necessarily open for reading.
Use SSL for secure connections. It uses asymmetric encryption, which means the key to encrypt the data is not the same that will be required to decrypt it. That way, even if attackers find out your encryption key, they still can't use it to decode. All major HTTP servers and client libraries support HTTPS, and that's what it does.
What "certain extent" do you think that is exactly? Every instruction and every piece of data your application contains is open to possible viewing. Besides, using the same key for every device is the ultimate in cryptographic insanity.
Just use HTTPS. SSL/TLS is a secure, proven technology built into every major HTTP server and every major HTTP client library.
You use a symmetric algorithm. Maybe you should consider to have an unsymetric method if you need a high security. That way you could even recreate the keys at i.e. every session and only need to exchange the public key.
Here some examples:
RSA
Diffie-Hellman
ElGamal
ECDSA
XTR
iOS has Keychain Services for storing things like encryption keys securely and (relatively) easily. Check out Keychain Services Programming.
All of the crypto APIs you're likely to need are also available in the CommonCrypto library included in libSystem. In short, there is no need to take shortcuts when it comes to securing your iOS applications.
As others have said, what you're proposing is completely insecure. If anyone cares about your app, they'll publish the secret key on the Internet within 10 minutes of its release.
Things you need to research are:
Asymetric encryption algorithms
Diffie-Hellman key exchange
(Note - I'm not saying those are the solution to your problem, but learning about them will educate you in the issues involved and better prepare you to pick a solution)
On an additional note, why can't you just use an HTTPS connection?
Finally, if this encryption scheme is protecting critical data, you'd probably be well served to hire a consultant to help you, since as a newbie to the subject, you're sure to make basic mistakes.