- docker
- docker-compose
docker-compose up -d --build # build the docker image and start the nodes
docker ps # check running containers
docker logs ${id} -f # show the streaming logs of container ${id}
docker-compose down # close and delete the nodesmiddleware for client side and server side proxy endpoint
protocal step:
-
define the proxy target for both client side and server side, where
proxy clientshould redirect toproxy server, andproxy serverredirect totartget api server. -
proxy servergenerate own$pk_{server}$ ,$sk_{server}$
proxy client$C_1$ generate own$pk_{c1}$ ,$sk_{c1}$
bothproxy serverandclientusing same public generater and prime number in this protocol -
User who is in client side want to send request to
target server, will request toclient proxywith same request body. -
after
proxy clientside receive the request, it'll check if it have encryption key withproxy server, if yes then goto 7. -
proxy clientsend key gen request toproxy serverwith it's public key$pk_{c1}$ , thenproxy serverwill compute their DiffieHellmon key and store inrediswithproxy client's host ip as key. Last,proxy serversend it's public key$pk_{server}$ as response. -
proxy clientreceive the$pk_{server}$ then compute theie DiffieHellmon key, and store the key as variable in memory. -
proxy clientthen encrypt the request body from user's request with the shared key, modify the request's header body size then send toproxy server -
after
proxy serverreceive the ciphertext, it's decrypt with theproxy client's host ip key inredis, if there are no such key inredis, then would response toproxy clientthat it should restart form 5. -
proxy serverdecrypt the ciphertext and set the plantext back to request body. last,proxy serverpass the request to thetarget serverwith decryption content. -
response body from
target serverwould also be encrypted byproxy server, using the shared key, and pass back toproxy client -
then
proxy clientwould decrypt the response body and replace with cipher body, then pass back to user.
sequenceDiagram
participant User
participant proxy-client
participant proxy-server
participant Redis
participant target
par keygen
proxy-server->proxy-server: keygen to get pk, sk
proxy-client->proxy-client: keygen to get pk, sk
proxy-client->>proxy-server: pk_c1
proxy-server->>Redis: Compute share key and store
proxy-server->>proxy-client: pk_server
proxy-client->proxy-client: compute share key and store
end
par request
User->>proxy-client: send request
proxy-client->proxy-client: encrypt the msg body
proxy-client->>proxy-server: send same request target with encrypted body
proxy-server->proxy-server: decrypt the cipher text
proxy-server->>target: the same request infomation as User to proxy-client
target->target: handle the api request
target->>proxy-server: send back the response
proxy-server->proxy-server: encrypt the response body
proxy-server->>proxy-client: send the cipher text body
proxy-client->proxy-client: decrypt the cypher text for th response body
proxy-client->>User: original response
end
if multiple server for handling high throughput event, we should set every server as same pk, sk key
set the
$sk_{server}$ toredisif not exist, then compute the$pk_{server}$
proxy-client: encrypt the request and decrypt the response
proxy-server: deal with encryption and the key gen algorithm
target server: return {"msg": "ok"} in 200 for every request showing the request is good
redis: read the key quickly and can share the shared key and the server secret key with all the other distribution servers
docker: easy deploying and system version controlling
redis-commander: GUI commander for checking the keys is stored correctly or not