#Secure, Fair Fantasy Sports Bernie Birnbaum and Shawyoun Shaidani

NOTE: Final, integrated product is in the folder labeled "unified." All filenames refer to the files in this location.

Compilation

Compile server as follows:
g++ -lssl -lcrypto -std=c++11 player.cpp demo_ssl_utils.cpp server.cpp -o server
Compile client as follows:
g++ -lssl -lcrypto -std=c++11 player.cpp demo_ssl_utils.cpp client.cpp -o client
Compile proxy as follows:
g++ -lssl -lcrypto -std=c++11 player.cpp demo_ssl_utils.cpp proxy_frontend.cpp -o proxy_frontend

Running the application

Note: in all versions, make sure the server has data file "nba1516.csv" in same directory as itself.

For basic application:
Run server with: ./server port Run client with: ./client serverhostname serverport

Note: in encrypted versions, make sure the server has a certificate file called "newreq.pem" in same directory as itself. One can be generated with the following command: openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 -keyout newreq.pem -out newreq.pem

For encrypted application:
Run encrypted server with: ./server (port) -s Run encrypted client with: ./client (host) (port) -s

For proxy application (in this order):
Run server with: ./server port -p
Run proxy with:./proxy_frontend port serverhost serverport
Run client with:./client proxyhost proxyport

##Use and test cases for standard application Start the server.
Connect and disconnect clients at will.
Follow prompt instructions to send messages, view drafted players, start the draft, draft players, etc.
Some suggestions:

• Log out and log back in with correct password (or risk getting booted with the wrong password!)
• Quit permanently and see that you are not remembered if you return
• Toggle draft readiness when you are the only client, and when there are others
• Conduct a full draft with multiple clients
• Run clients with different latencies side by side, see that both have the same window for response, receive draft related messages in within the same RTT, and that the quickest reaction is rewarded
• Have everyone ready to draft except one client and have that client quit
• Log out during a draft...then log back in, see your team remembered and resume drafting
• Finish a draft and see results outputted to a distinctly named file
• Have the slowest client leave and observe increased draft speed...or have a slow client log in and see the opposite
• Log out and log back in with different latency
• Use a connection with variable latency and notice the engine adjust over time
• Use a debugger to verify that the passwords are encrypted
• Sever the connection between the client and the server to demonstrate the offline abilities of the client
• Send chat(s) in between draft rounds; observe next round will wait until you are done
• Attempt login as a client that is already present, or as an absent client using a bad password, and see that the offending client is terminated without affecting anything else
• Anything else you can think of! (Hopefully we've handled it :P)

##Use and test cases for secure application:

• Start the server in secure mode (-s).
• Start a secure client pointing to the server. Select any of the options for TLS, then anything but "y" for prompt about trusting self-signed certificates. Observe that the handshake fails because the cert cannot be verified.
• Run ssldump against the interface of the client or server. Start a client again, using any of the TLS options, and this time type "y" for the prompt about trusting self-signed certs.
• Observe in ssldump output that the handshake has taken place. Also note the version of TLS used (TLS 1.0 appears as SSL 3.1, 1.1 shows up as 3.2, 1.2 is 3.3) and verify it matches what you requested. Vary versions for different clients to same server.
• As you begin using application, confirm that ssldump is showing this as "application data." In unencrypted mode, none of this data would show up in the output.
• Using packet sniffer like Wireshark, confirm that the data is scrambled. Compare to unencrypted mode, where you can observe the traffic in plaintext.
• In the logout (not permanent) case, verify in ssldump that a new handshake is done when the client returns.
• Try connecting to secure client with insecure client, and secure client with insecure server. Verify that the connection eventually fails.
• Follow same steps as above ("Use cases for normal application") and verify that behavior is still the same at endpoints.

##Use and test cases for proxy application:

• Run the server in proxy mode (-p), then have proxy_frontend connect to it. Run the client and connect it to the proxy frontend.
• Watch traffic on the wire (Wireshark or tcpdump) and verify that it is all going through proxy_frontend instead of directly between client and server.
• Run sockets tool "ss -t" to see number of sockets opened up on each host/port combination. Verify that each client has a pair of sockets (read / write) against the proxy_frontend, but there's only pair between the server and proxy_frontend.
• After connection has been established between proxy_frontend and server, try to connect directly to the server as a client. Verify that the connection is killed (it briefly accepts, then closes immediately).
• Disconnect from proxy_frontend (CTRL-C or logout) and verify that you have to be authenticated afterwards (server prompts you for password and says "welcome back" with your data if correct.) The server was made aware that you disconnected from the proxy.
• Follow same steps as above ("Use cases for normal application") and verify that behavior is as expected.