It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
When we use SSL(Secured Socket Level) Server has private key whereas client has public key.
In such cases client encrypt data and server decrypt it to get actual details, but how it will work if server is sending some critical financial details to client. In this situation as client has only public key so whether it is possible for key to decrypt details.
In short how secure communication from server-->Client works.
Public key cryptography is only used during the SSL/TLS handshake to agree on shared keys. The encryption/decryption of the data on top of SSL/TLS is then done using these shared keys.
You should read about Diffie-Hellman Key Exchange and RSA Key Exchange.
Here is a document describing the principles of the key exchange: http://technet.microsoft.com/en-us/library/cc962035.aspx
There is also a description of how this applies to SSL/TLS here: http://technet.microsoft.com/en-us/library/cc783349%28WS.10%29.aspx#w2k3tr_schan_how_eicp
Well, in reverse? The server logs in to the client with ssl in the same way as the client would log into the server? That is, if you require a separate connection. If the server sends back the sensitive information within the same secure session, there is no security problem.
But maybe I don't understand your question correctly :)
I think that after server sends his key to client, client can generate a private key and send it over SSL to the server. After that both client and server can use their private key to comunticate. I'm not an expert but that make sense
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm designing a web API that will give an opprtunity for clients(other apps) to push some work request, receive immediately some id of that work request and later receive the result of that work request.
What is the typical approach for such kind of interactions?
As providing the result of work request reminds me server push interaction I thought about SSE(server sent events) and webscoket technologies, inclinig to websockets(as client may use the same connection for all kind of requets and receive all kinds of response). Is it a good choice for my goal? and how this can be scaled?
The question is about whether websocket technology suits for the described approach of api design and if not I'm wondering what is a better approach. Is it a good choice for my goal?
A webSocket connection is very well suited for receiving results back at some indeterminate time in the future and it would be a recommended way to do this.
Other requests from the client to server can either be ajax calls or sent as webSocket messages, mostly depending upon whether there are other reasons to make the requests as ajax calls or not. If you already have an established webSocket connection, then it is a convenient, easy and fast way to communicate with the server.
Taking the individual parts of what you doing:
Pushing some work request (from client to server).
This can be done equally well via Ajax or webSocket. If there was no other reason to have an already established webSocket connection, then this would traditionally be an Ajax call.
receive immediately some id of that work request
This is actually a little easier to do with an Ajax request because Ajax is a request/response protocol so if you send the work request via Ajax, it would be trivial to get the ID back as the response to that Ajax request. You could also do it via webSocket, but webSocket is just a messaging protocol. When sending the work request to the server, you could send it via a webSocket (as mentioned previously). And, the server could then immediately send back the work ID, but the client would have to develop some way to correlate the work ID coming back with the previously sent request since those two messages would not have any natural connection to one another. One way that correlation could be done is to have the client generate a temporary ID or hash value when sending the initial request (it can literally be anything that is unique for that client such as a timestamp) and then the server would send that same temporary ID back when it sends the work ID. All this is trivial with a request/response protocol like HTTP/Ajax.
later receive the result of that work request
HTTP Polling, webSocket or SSE could all be used. Polling is obviously not particularly efficient. I know a webSocket would work perfectly for this and it would provide an open conduit for any other items the server wants to send to the client in a push fashion. SSE can also be used to solve this problem (pushing data to a client) though I don't personally have any experience with it.
I'm trying to use the Qt Cryptographic Architecture to generate public/private key pairs for nodes, and want to have a protocol in which nodes confirm that a message came from a given source (public key) by issuing a challenge to ensure they are the owners of the corresponding private key. I'm a little stuck on the actual syntax for QCA though ...
This should get me a private key, from which I can also get the public key:
QCA::KeyGenerator generator;
QCA::PrivateKey privateKey = generator.createRSA(1024);
Does QCA already have some sort of challenge protocol built in? If so, how can I use it? If not, how can I apply some of the standard cryptographic challenge protocols using these keys? I'm really just trying to demo a simple security concept - I'm not looking for anything complicated or even particularly robust.
Also, this is a side question, but since I don't need encryption, should I be opting for DSA as opposed to RSA?
There are more than one of doing that. But since all clients already have their asymmetric key pairs you may deploy two-way TLS in establishing connection.
In this scheme both client and server allow establishing connection only, if they trust certificates (public keys) of each other. This guarantees client authentication and non-repudiation.
From your side you will need to provision server certificate to all clients and all client certificates to the server. To avoid dealing with certificate authorities, certificates could be self-signed.
QCA has examples for TLS client and server.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I recently am attempting to study the TCP, but a post graduate tell me the FIN is also used in going to create a connection, that 3 handshakes.
Following is my mind to the process of 3 handshakes:
Client A post a datagram within SYN to Client B.
Client B received it, and immediately posted another datagram within SYN and ACK.
Client A received it, and immediately posted another datagram within ACK to Client B.
When the 3rd step is DONE, the connection is going to be built.
Here is the question, I don't find any datagram with FIN in 3 steps.
FIN is not used in creating a connection. It's used to close a connection.
However, the connection can be closed with FIN halfway through a handshake, as this diagram makes clear. Perhaps this is what the Post Grad was referring to?
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
According Google the following are the facts on usage of ports:
The Well Known Ports are those from 0 through 1023. The Registered
Ports are those from 1024 through 49151 The Dynamic and/or Private
Ports are those from 49152 through 65535
How can i connect more than 65535 users to a single server. because we need to provide a socket to every new listening connection? so wont it create a new port locally for every connection?
A single connection is defined by pair IPserver:server_port and IPclient:client_port. Given that you server_port is just one and is fixed, and your client is defined by IPclient:client_port, it gives a theoretical range of 2^48(32 of IPv4 + 16 of PORT) different clients, so you can have 2^48 parallel connections to a single server.
The limit is that you can't set more than 2^16 connections from a single IP to a single server.
All incoming connections to a listening port use that port. So your problem does not exist, unless you mean you want more than 65535 connections all from the same client host, which would be a strange requirement.
One IP address can only hold a 2 bytes port, as is defined in TCP and UDP protocol. One possible workaround can be like this:
server fork n processes, echo listening on 192.168.0.(10+i):9999.(i = 0 to n-1)
clients try to connect 192.168.0.10:9999, if fail(192.168.0.10 has no more ports available thus connection cannot be established), then try 192.168.0.11:9999 and so on.
As to how to bind multiple IPs to a single NIC, check this: http://community.spiceworks.com/how_to/show/1782-bind-multiple-ips-to-one-nic-in-linux
Can a Diffie-Hellman key exchange algorithm be used to encrypt client-server communication on a web-page in place of SSL? If it can, what are the disadvantages (i.e. why does the standard use SSL which requires a certificate authority)? My understanding is that Diffie-Hellman can be used to secretly establish a shared key which then can be use to encrypt any further communication.
The two aren't really comparable. DH is a key-exchange algorithm, nothing more and nothing less. SSL attempts to establish that the server you're connecting to is really who it says it is. To do that, it uses a certificate that can be traced back to somebody you (are supposed to be able to) trust.
DH, by itself, only keeps others from reading the transmitted data. SSL is intended to establish considerably more than that (but can use DH to keep others from reading the stream).
Just for an obvious example, using DH (by itself) a Man in the middle attack is fairly simple. If I can get you to connect to my server instead of the one you intended to, I can use DH to establish a "secure" session with you. I then connect to the server you originally intended to. Every packet I get from you, I decrypt, re-encrypt with a key I used to connect to that server, and send on to that server. I do the same with all its response packets. To you, everything looks like it came directly from the original server, and the purchase you made (for example) works just like normal. The only thing that changes is that I also store your credit card number, and when you try to fill your car with fuel the next day, the charge is declined, because in the meantime I've spent all your credit.
The authentication in SSL is at least intended to prevent that from happening. If your browser tried to connect to (for example) www.amazon.com, it should give you a warning if my SSL certificate doesn't specify that it was issued to www.amazon.com -- and a CA shouldn't issue such a certificate to anybody but Amazon.
DH, by itself, doesn't really even guarantee most of what I've said above. By itself, DH is just a way to exchange a key (or, perhaps it could be phrased as "exchange information necessary for both parties to create identical keys, without ever exchanging the key itself in the clear"). After both parties have the key, they can (and presumably will) use it to encrypt/decrypt data -- but that encryption is actually separate from DH itself.
Actually Diffie-Hellman is a part of SSL.
But one part does not replace others.
From here SSL Diffie-Hellman is used for:
This a Diffie-Hellman key exchange in
which the server's certificate
contains the Diffie-Hellman public
parameters signed by the certificate
authority (CA). That is, the
public-key certificate contains the
Diffie-Hellman public-key parameters.
The client provides its Diffie-Hellman
public key parameters either in a
certificate, if client authentication
is required, or in a key exchange
message. This method results in a
fixed secret key between two peers,
based on the Diffie-Hellman
calculation using the fixed public
keys.
You can use anonymous Diffie-Hellman key agreement with SSL. This provides privacy on the channel, but no authentication.
Of course, without authentication, you really can't have privacy, because your private channel could be connected to a "man-in-the-middle". That's why the anonymous DH cipher suites are discouraged.
If the lack of a certificate is stopping you from using SSL where it's really needed, get a free one from startcom.org.
Diffie-Hellman key exchange is only for keyexchange. It does not give you authenticitation (who you're talking to), you need certificates and a PKI for that.
So yes you can do encryption, but you dont know with who you're talking to
The DH key exchange cannot, of itself, do encryption. It is used to establish a session key, but not to do the encryption. So, at this level, the question is mis-stated or reveals either lack of precision or lack of understanding (I suspect precision is the problem this time).
The question is:
Do you want to encrypt data with anybody at all?
Do you want to be sure who you are talking to?
As already pointed out, SSL uses a DH key exchange to establish a session key. However, it also ensures that the program on the other end is someone you trust (directly or indirectly). If you don't need to worry about whether the other person is trustworthy, you could just use a simple DH key exchange and then send encrypted data without needing certificates. But you won't be sure who you are talking to unless you validate that - and the certificates used by SSL etc helps with that validation.