« first day (2079 days earlier)      last day (2801 days later) » 

5:11 AM
Hello! Could anyone with some 802.11 protocol experience give me a feedback on my answer to my own question? I'd like to know if my theory actually fits what is going on. If so I'd accept it for further reference. (link: security.stackexchange.com/questions/134490/…)
Thanks!
 
 
6 hours later…
11:13 AM
Hello and a good morning/afternoon/night. Need some help. So we have a client, an intermediate server (let's call it storage server) and a final server (let's call it counting server). The client needs to transfer some confidential data that will be consumed by the counting server in the end. However, client will be talking to the storage server. There is anyway (preferably through SSL) through which we can encrypt the data that the storage server shouldn't be able to read?
 
11:52 AM
What is the tech you are using? Web-browser or a dedicated client ?
 
Not sure I understand, you want the client to essentially to send data directly to the counting server, but they only have access to the storage one? Or do you want the client to store data on the storage one, but make sure that it isn't accessible to anyone having access to it?
 
Thanks for the response. So the client will be interacting with the storage server. The counting server will then take the data stored in the DB of the storage server to process. HTTPS ensure confidentiality between client and storage server only. How can be ensure that a particular field of data is not readable by the storage server
@M'vy Web browser
Can we use HTTPS with HSM so that when the data is received by the storage server, it passes it on to the HSM and we ask the HSM to encrypt it with a different key before storing it in the DB?
 
Is there a particular reason you don't trust the storage server ?
 
@M'vy Just not trusting it with one particular data piece
That the client will be sending
And will be ultimately processed by the counting server
 
I mean you could encrypt the field in the database using a password know from storage and counting servers
 
12:02 PM
Storing the data such that it isn't accessible to you (storage) is quite easy. But you (counting) need to be able to read it to process it. If it's the same "you", then you have some problem...
 
So that if your DB is dumped there is no way to recover the field.
Of course you have to trust the server admin in my use case. It does not protect from internal threats or full privileges exploits
 
@M'vy or client and counting server.
 
@bilbo_pingouin It is not "me". Counting server is a completely separate entity. If we use HTTPS, it is terminating on the storage server and hence it is able to read the full packet
 
@bilbo_pingouin that too, but more complicated.
cause you'd need the client to negociate that key with the counting server, at least once
 
@M'vy yeah, but if you absolutely don't trust the middle one, that way you ensure he can't know anything
 
12:06 PM
It this feasible that that a JS code in the client browser talks to the HSM to encrypt a field of data that we then send to the storage server where it is saved? The communication between client and storage server is already over HTTPS
*Is it
 
@void_in HTTPS means that I am not able to get the data between your client and storage. It does not imply any encryption for either the client or storage.
 
Client + HSM? I doubt that. Though I don't know much about HSMs
 
@bilbo_pingouin You are right. It is security in transit
 
I guess you could encrypt stuff using the counting server TLS cert if the client can get it somewhere ?
but it means a client specific code to handle the asym crypto
 
@M'vy The problem is that counting server is not online. It will only become online when required
I mean data will be stored in the DB on the storage server for a few days and then counting server will come online and start processing it
 
12:10 PM
could the storage server serve the counting server public cert ?
 
@M'vy Yes
 
preferably using the DNS name of the counting server.
then the client app/script/whatever verifies the cert signatures and revocation lists
then use the public key to encrypt it's stuff
and sends the encrypted input to the storage server.
This means asymmetric crypto, hence lot of computation forclient and counting srever
 
How will the storage server sends the certificate of the counting server?
 
as it would with any TLS certificate?
you just have to configure the webserver to serve counting-server.com using only the public cert (if that's possible... < that is a good question in fact)
 
@M'vy I think what you are proposing is a very elegant solution. Let me think about it and will get back if there are some problems. Thanks a lot. Really appreciate your time and help
 
12:17 PM
It's a complicated use case. Not sure I understand all the threats here, so careful in implementing what I say :)
 
@M'vy :) Yeah
 
(well actually I'm a total stranger to you, so of course you should doubt everything I just told you :) )
 
 
9 hours later…
8:48 PM
Hey is there a way to stop nmap and get the results found so far?
 

« first day (2079 days earlier)      last day (2801 days later) »