I have another question to security in the web world.
So I read (and ask :P) about certificates and think I got what it is and how it works. My next question is putty specific. When I open a connection with putty to a new server with ssh (port: 22) I get a PuTTY Security Alert:
The server's host key is not chacked in the registry. You have to guarantee that the server is the computer you think it is.
The server's xxxx key fingerprint is:
yyyyyyyyyyyyyyyyyyyyyyyyyyy
If you trust this host, hit Yes... etc.
Now I am wondering what a key fingerprint means.
Is that just a certificate which putty hasn't in is cache yet?
thanks.
SCBoy
Those are the first bytes of the server certificate public key. The idea is that the key is a random number, so the first bytes are random too and therefore knowing that those first bytes are the same for two keys would likely mean that the keys are actually the same.
You can use this to validate the server. You could for example call the administrator of that server and ask him for the fingerprint of the key to validate that it's indeed the key of that server, not some man-in-the-middle server belonging to a malicious party.
Related
I am currently developing an MQ application client-side, that is meant to establish connection between a machine and a distant server, and I need to implement SSL connection between them. The server was already configured with a given certificate that I was sent. The problem is : I can't understand what exactly needs to be done with the key repository part.
It looks like the MQCONNX call is expecting not only a certificate name (label), but also a key database (kdb) file, which I don't have. Thus I have several question, because it seems like I don't understand every aspect of the certificate part:
How can I get the kdb file linked to the certificate? Is it supposed to be generated by the person who made the certificate?
Where is it supposed to be stored? Can I use any folder/name?
A little background : I am working on Windows and developping with C MQ libraries. Before the SSL requirement was added, everything was working properly : I could connect to the queue manager and post messages into a given queue. Now I get error 2381 MQRC_KEY_REPOSITORY_ERROR, which will probably be gone after this key repository part is solved.
Thanks a lot for all your answers.
Cheers,
I think between them the comments to your question provide the answer. In essence your client application (or the underlying MQ C layer) needs to trust the certificate that the server is sending.
If the certificate you have was signed by a trusted certificate authority,
then your app needs to be told to trust the public key of the certificate authority. If it is self-signed, then your app needs to be told to trust the public certificate.
Either way, you will need a keystore. The keystore holds all the public keys and public keys of certificate signers that you trust.
To create the keystore, follow the "Create a client keystore" section of https://developer.ibm.com/tutorials/mq-secure-msgs-tls/
These steps will create a keystore containing the certificate that you have been sent.
You then tell your application where to find the trusted keys keystore by setting the environment variable MQSSLKEYR
// MQSSLKEYR is need so that the MQ client knows what keystore to use..
// note it is the full path, including the base file name but not the .kdb extension
// my keystore file is user.kdb in the C:\tmp subdirectory..
set MQSSLKEYR=C:\tmp\user
see - https://www.ibm.com/docs/en/ibm-mq/9.0?topic=wsulw-specifying-key-repository-location-mq-mqi-client-unix-linux-windows
and
https://www.ibm.com/support/pages/how-do-i-configure-mq-client-c-based-application-amqsputc-amqsgetc-connect-mq-server-ssl
Assume, I have two choices.
Use self-signed x.509 certificate on both the server and client and validate server using its certificate stored in client and authenticate client using client certificate stored in server.
Create only keys on both the server and client and validate server using server key stored in the client and authenticate client using client key stored in the server.
Assume we will use RSA with key length of 2048.
My query is what will be the performance difference. My worry is overhead involved in taking key out of certificate and doing channel encryption.
Our case is there will more number of requests and not much data to flow.
Let me know if you have any queries or concerns.
SSL and SSH they are all have the same functionality, which is Encryption. Both are Cryptographic Network protocols.
SSL:
port: 443
Application : Encryption between browser and server
SSH :
port : 22
Application : Between two Computers
This is the picture of Version Control system which has got SSH key to communicate between user and their repository!
Know how to generate SSH key Here!!
Know how to Generate SSL key Here!!
Credits :Medium
Excuse me if this question is really naive, but I searched as much as I could without being able to find relevant answers.
I spent the last three days trying to understand how https works.
All I knew before these days is how symmetric and asymmetric cryptography works.
It was about time for me to understand how these two are applied on ssl-https and achieve the so called data encryption and server identity verification.
Everything is clear regarding the data encryption and the prevention of man-in-the-middle attacks
It seems though that I don't completely understand how server identity verification works, so your help will be highly appreciated.
My understanding so far is the following:
When a client connects to a server via https, the server sends a signed by a CA certificate.
This server certificate is a text file containing information regarding the server(name, owner email, public key etc..), plus a digital signature.
This signature is a hash of the content of the server information, encrypted by the CA private key.
The client checks the validity of the signature by producing again -on his own- the hash of server info and decrypting the signature using the CA's public key. If the decrypted signature value is the same with the produced hash, the signature and the certificate subsequently are valid.
Note here that the public-private encryption scheme has a dual nature. A message can be encrypted by the public key and decrypted by the private key. The same message can be encrypted with the private key and decrypted by the public key as well.
What we need to keep in our minds here is that the certificate is a static and non change-able file. Any change on the file will result in a signature mismatch.
I will describe now a way to fool https:
Lets say theres an ebanking site with URL = https://wwww.TheBank.com/ebanking (public IP = 195.134.0.1)
I connect to this URL and my browser gets the server certificate. (theBank.cer)
On the same time I'm the owner of an internet cafe. My internet cafe has its own router, DNS and DCHP servers which I have the knowledge to control. It has a web server as well.
I configure the web server to own ip 195.134.0.1, same as the bank's
I create a route to my router that sends connection requests for 195.134.0.1 to my web server
I configure my DNS to point the above bank URL to 195.134.0.1(my web server)
I place a fraudulent bank site on my web server. For any connections on this site, I instruct the web server to send to the client the certificate I downloaded before.( theBank.cer)
A user comes to my cafe, gets connected to my network and attempts to connect to this bank. My server sends to him the certificate of the bank. His browser will confirm the validity of the certificate, since its indeed the valid one and allow a connection to my fake web site since its URL, IP and hostname are the same with the real one.
So my fraud is successful.
Of corse, this security hole is too obvious to be true. Meaning I haven't understood something in this server identity verification procedure. Can someone please explain to me what I am missing here?
A user comes to my cafe, gets connected to my network and attempts to connect to this bank. My server sends to him the certificate of the bank. His browser will confirm the validity of the certificate, since its indeed the valid one and allow a connection to my fake web site since its URL, IP and hostname are the same with the real one.
Once his browser has confirmed the validity, it knows the bank's real public key, since that's in the certificate. Since your server can't sign anything with the private key corresponding to that public key, nor can you decrypt anything encrypted with that public key, you can't impersonate the bank at all. All you can do is convince the user of the bank's real identity, which you can't impersonate.
I think the key thing you're missing is that the primary purpose of a certificate is for a trusted authority to bind a real-world identity to a public key, such that only the owner of that real world identity knows the corresponding private key.
theBank.cer is a public key.
You cannot use it to decrypt or sign anything.
This signature is a hash of the content of the server information,
encrypted by the CA private key.
The client checks the validity of the signature by producing again -on
his own- the hash of server info and decrypting the signature using
the CA's public key. If the decrypted signature value is the same with
the produced hash, the signature and the certificate subsequently are
valid.
This is more or less what happens with RSA, but not with DSA, which is signature only (no encryption).
In general, you shouldn't talk about "encrypting" with a private key. It doesn't make any sense, since anyone would be able to decrypt with the public key (since it's public). Encryption is about hiding information.
What you can do with a private key is sign and decrypt/decipher. What you can do with a public key is encrypt and verify a signature.
If you mix up when encryption is required and when signatures are required (despite the fact the algorithm are very similar with RSA), you can end up designing systems that don't provide any security.
More generally, the purpose of a public key certificate (X.509 certificate, or even PGP certificate) is to bind an identity (e.g. the server host name) to a public key. (See this question on Security.SE.)
The data my web server will receive will be encrypted by the public
key of the bank
Note that the SSL/TLS traffic is not encrypted using the certificate's private key, but shared keys negotiated during the SSL/TLS handshake.
During the SSL/TLS handshake, that public key is used either to encrypt the pre-master secret or to sign other parameters (depending on the cipher suite), which end up proving to the client that it's communicating with a server that has the private key for this public key.
Since the certificate also binds the server name to the public key, the client then knows it's communicating with the right server.
This is why it's important to verify that (a) the certificate is trusted and (b) it's issued to the server name the client wanted to connect to.
I've just been doing a bit of wondering and learning, and I wanted to know how this works. I'm pretty sure I understand the concept of public/private key pairs, as i've gotten it to work with ssh, but I was wondering about https sites too. Where does my machine get the key pairs. Does chrome automatically generate a new key pair every session? Is there one hidden on my machine I don't know about?
I could be getting this all wrong, but any help would be great. :)
Browsers only generate key-pairs when the user needs to request a new (typically client) certificate. This is not necessarily related to SSL/TLS, but more of a convenience facility to issue certificates. This has nothing to do with day to day use of HTTPS. (Even if you are using a client-certificate, you only generate the key-pair when that certificate needs to be issued/renewed, typically once a year.)
The keys used for encryption are symmetric keys, negotiated during the handshake, where only the server certificate is required (for authenticated negotiation). You may find more details in this similar question: Can One Public Key be Used to Encrypt and Decrypt Data during the SSL Handshake?
Yes your browser generates only symmetric keys
see http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.itame2.doc_5.1/ss7aumst18.htm
I want to encrypt passwords using the DPAPI like this
ProtectedData.Protect(plain, optionalEntropy, DataProtectionScope.CurrentUser);
and wonder if the domain administrator could decrypt the generated blob, as
Using Passwords Effectively states:
However, in a domain environment a
domain administrator can safely change
your password, and you'll still have
access to your encrypted files.
It seems like the domain administrator would have to decrypt the data (or rather, the encrypted master keys) first, in order to be able to re-encrypt it using a different password.
The answer is yes, provided he also has acces to the entropy key(if one is created), or if he is willing and capable enough to hack into the blobs (see links below).
For the Master key in DPAPI (in CurrentUser mode), the windows login username and password are used to generate the master key.
If the administrator updates the user's domain password, DPAPI wil reencode the master key for that user. The same goes if the user updates his password due to eg. a monthly password change policy.
However, if he doesn't have access to the optional entropy key or the data that composes that key, the file will remain encrypted and all he will get is invalid data.
If DPAPI is used in CurrentMachine mode, the file can only be decrypted on the computer that encrypted it, however the file will be readable to all accounts on that computer, again provided they can also muster the content of the entropy key.
A good repository for information is DPAPI Secrets and this paper on reverse-enginerring DPAPI + link to a tool that can recover data from DPAPI blobs
Short answer : he probably can't right out of the box, but Domain Admin is powerfull. There are many ways they can get to your key if they really want it.
Long answer : DPAPI encrypts your data with a key. IIRC, it uses AES with a key that changes every 90 days. The key is stored on your computer, encrypted with your password. That's the default and it saves your key out of reach of anyone but you.
Unless your domain admin remotely installs a key logger, steals your password, impersonnate you and steal your key (or go straight to the data which he now sees in plain text).
Another somewhat less known fact is that when Credential Roaming is enabled on Active Directory, it will send your encrypted keys to a server. A domain admin could use that copy for an offline attack. But it is hard and unless your data is very valuable, I woulnd't worry about it.
The answer is yes. PoC utility with description: Vulnerability of DPAPI data protection in Win2K, Win2K3, Windows Server 2008, and Windows Server 2012
Works in Win Server 2016/2019 as well.