HTTP Reverse Proxy
Application layer, cant present proxy destination certificate cause TLS handshake already being done at host
apache can only do HTTP reverse proxy
TCP/IP proxy pass
reverse proxy tcp packet, will present server certificate at destination instead of host,
Nginx can do it, go can do it
Nginx:
stream {
map $ssl_preread_server_name $target {
example.com 10.0.0.12:443; # Server B
default 10.0.0.11:443; # Server A
}
server {
listen 443;
proxy_pass $target;
ssl_preread on;
}
}
HA Proxy has higher performance, but due its configuration based its hard for customized logic
GO has a realtively good performance, good at handling customized logic, one goruoutine handles one request, and go routine is not 1:1 thread to OS thread
JVM thread is OS thread worst of all
https://samsadsajid.medium.com/designing-a-reverse-proxy-why-golang-performs-better-than-java-spring-boot-an-in-depth-analysis-dc43de9861c7
https://serverfault.com/questions/618957/dynamic-haproxy-configuration#:~:text=If%20you%20authorize%20your%20stats,can%20send%20commands%20to%20it.&text=Mark%20the%20server%20DOWN%20for,centrally%20manage%20that%2C%20of%20course.
Generally go lang is good for customization, if you really have millions of request, u can do customizations with GO such as API and proxy with HA proxy
check if system is using systemd-resolved
systemctl status systemd-resolved
change global dns
sudo nano /etc/systemd/resolved.conf
[Resolve] DNS=8.8.8.8 1.1.1.1 FallbackDNS=8.8.4.4 1.0.0.1
sudo systemctl restart systemd-resolved
// check resolve status (You have to create a seperate network file if u are not using global but a specific network interface)
resolvectl status
// Two approaches for a specific network interface
ls /etc/systemd/network/
sudo nano /etc/systemd/network/<networInterfaceId>.network
[Match] Name=enp0s3<networkinterfaceId>
[Network]
DNS=8.8.8.8
DNS=1.1.1.1
sudo systemctl restart systemd-networkd * Might need to reboot machine
---------onetime solution(not recommneded)
Unlink the Current /etc/resolv.conf:
bash
Copy code
sudo unlink /etc/resolv.conf
Create a New /etc/resolv.conf File: Manually create the file with your preferred DNS servers:
bash
Copy code
sudo nano /etc/resolv.conf
Example content:
plaintext
Copy code
nameserver 8.8.8.8
nameserver 1.1.1.1
Prevent systemd-resolved from Recreating the Link: Mask the service if needed:
bash
Copy code
sudo systemctl disable --now systemd-resolved
sudo systemctl mask systemd-resolved
Verify the New Configuration: Check that the changes are applied:
bash
Copy code
cat /etc/resolv.conf
https://ubuntu.com/server/docs/configuring-networks
You can always use ubuntu UI to do it,
but to do it in cmd line way :
show gateway:
ip route show
default via 10.102.66.1 dev eth0 proto dhcp src 10.102.66.200 metric 100
10.102.66.0/24 dev eth0 proto kernel scope link src 10.102.66.200
10.102.66.1 dev eth0 proto dhcp scope link src 10.102.66.200 metric 100
add default gateway:
sudo ip route add default via 10.102.66.1
add DNS
sudo vim /etc/resolv.conf
nameserver 8.8.8.8
nameserver 8.8.4.4
https://stackoverflow.com/questions/72866563/what-are-bag-attributes-in-pemfiles-and-do-they-matter-in-the-file-i-mean-can
ag attributes are generated by OpenSSL during PFX conversion to PKCS#1/PKCS#8 PEM private key files. These attributes are not signed and are completely optional. See this thread for more information: What are bag attributes and how can i generate them?
https://www.globalsign.com/en-sg/blog/what-is-a-certificate-signing-request-csr
https://en.wikipedia.org/wiki/Certificate_signing_request
What is certificate sign request(CSR)
Before creating a CSR for an X.509 certificate, the applicant first generates a key pair, keeping the private key of that pair secret, e.g.:
The CSR contains information identifying the applicant (such as a distinguished name), the public key chosen by the applicant, and possibly further information. When using the PKCS #10 format, the request must be self-signed using the applicant's private key, which provides proof-of-possession of the private key but limits the use of this format to keys that can be used for (some form of) signing. The CSR should be accompanied by a proof of origin (i.e., proof of identity of the applicant) that is required by the certificate authority, and the certificate authority may contact the applicant for further information.
Typical information required in a CSR (sample column from sample X.509 certificate). Note that there are often alternatives for the Distinguished Names (DN), the preferred value is listed.
| DN[2] | Information | Description | Sample |
|---|---|---|---|
CN | Common Name | This is fully qualified domain name that you wish to secure | *.wikipedia.org |
O | Organization Name | Usually the legal name of a company or entity and should include any suffixes such as Ltd., Inc., or Corp. | Wikimedia Foundation, Inc. |
OU | Organizational Unit | Internal organization department/division name | IT |
L | Locality | Town, city, village, etc. name | San Francisco |
ST | State | Province, region, county or state. This should not be abbreviated (e.g. West Sussex, Normandy, New Jersey). | California |
C | Country | The two-letter ISO code for the country where your organization is located | US |
EMAIL | Email Address | The organization contact, usually of the certificate administrator or IT department |
This sample command line uses the details as listed in the table above:
The client sends session key information, encrypted with the server's public key.
The server decrypts the data sent using its private key. The data is used to create a symmetric key.
The client sends its digital certificate, which includes its public key.
The client sends "Certificate Verify" message, which is signed using its private key.
The server verifies the client's certificate and "Certificate Verify" message using the client's public key.
The client and the server exchange "Finished" messages, encrypted with the symmetric key.
CA sign CSR
https://www.ibm.com/docs/en/license-metric-tool?topic=certificate-step-2-signing-certificates
openssl x509 -signkey path_to_CA_key.key -days
number_of_days -req -in path_to_CA_csr.csr
-out CA_certificate_name.arm -sha256
Most common/simple renewal:
existing files:
server.key
server.crt
ca.crt
ca.key
server.ext
This keeps the same server.key.
openssl req -new -key server.key -out server-renew.csr
Use the same Common Name as before, for example:
mydomain.com
openssl x509 -req \
-in server-renew.csr \
-CA ca.crt \
-CAkey ca.key \
-CAcreateserial \
-out server-renew.crt \
-days 365 \
-sha256 \
-extfile server.ext
Now replace the old cert:
cp server.crt server.crt.bak
cp server-renew.crt server.crt
Your pair is still:
server.crt
server.key
Then restart/reload your server.
------need a server.ext
server.ext can be just:
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage=digitalSignature,keyEncipherment
extendedKeyUsage=serverAuth
subjectAltName=@alt_names
[alt_names]
IP.1=160.223.160.145
You only add DNS lines when clients connect using a domain name, for example:
[alt_names]
DNS.1=example.com
DNS.2=www.example.com
IP.1=160.223.160.145
So the rule is:
Client connects to https://160.223.160.145 -> use IP.1
Client connects to https://example.com -> use DNS.1
make p12:
openssl pkcs12 -export -in jxiangclientdev.crt -inkey jxiangclientdev.key -out jxiangclientdev.key.p12
https://www.techtarget.com/searchsecurity/definition/mutual-authentication
The steps required for mutual authentication include the following:
Client sends a "Client Hello" message to the server that includes the TLS versions, the cipher suites and data compression methods the client uses.
The server responds with a "Server Hello" message that has its TLS, cipher suite and data compression choices from among the options the client provided.
The server also provides a session ID and a client certificate request.
The server sends its digital certificate, along with its public key.
The server sends a "Server Hello Done" message.
The client verifies the server's certification information.
The client sends session key information, encrypted with the server's public key.
The server decrypts the data sent using its private key. The data is used to create a symmetric key.
The client sends its digital certificate, which includes its public key.
The client sends "Certificate Verify" message, which is signed using its private key.
The server verifies the client's certificate and "Certificate Verify" message using the client's public key.
The client and the server exchange "Finished" messages, encrypted with the symmetric key.
https://stackoverflow.com/questions/3936071/how-does-browser-generate-symmetric-key-during-ssl-handshake
Then master key is produced by both parties in following manner:
master_secret = PRF(
pre_master_secret,
"master secret",
ClientHello.random + ServerHello.random
)check server
openssl s_client -connect IP:PORT -status -showcerts </dev/null
chain
Acceptable client certificate CA names
C = US, ST = California, L = dev, O = dev, OU = Certificate Authority, CN = dev1, emailAddress = dev
C = US, ST = California, L = Sunnyvale, O = dev, OU = Certificate Authority, CN = dev2, emailAddress = dev
Client Certificate Types: RSA sign, ECDSA sign
Requested Signature Algorithms: RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:ECDSA+SHA256:RSA+SHA384:ECDSA+SHA384:RSA+SHA512:ECDSA+SHA512
Shared Requested Signature Algorithms: RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:ECDSA+SHA256:RSA+SHA384:ECDSA+SHA384:RSA+SHA512:ECDSA+SHA512
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: ECDH, P-256, 256 bits
single
Acceptable client certificate CA names
C = CA, ST = BC, L = VAN, O = Fortinet, CN = dev, emailAddress = dev@dev.com
Client Certificate Types: RSA sign, ECDSA sign
Requested Signature Algorithms: RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:ECDSA+SHA256:RSA+SHA384:ECDSA+SHA384:RSA+SHA512:ECDSA+SHA512
Shared Requested Signature Algorithms: RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:ECDSA+SHA256:RSA+SHA384:ECDSA+SHA384:RSA+SHA512:ECDSA+SHA512
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Postman, curl, snow validation :
curl flag -k (insecure to ingore)
postman: settings -> SSL certification verification
SNOW cant turn off,
to ensure self signed certificate, ensure server certificate has subjectAlternativeName: host:"<IPADDR>" can match server IP
Then ensure curl has
-cacert fCA.crt for curl
curl --verbose can give detail handshake info
and postman -> settings -> certificate -> CA certificate
-----------------------------------------------
SNOW will validate server certifiate, subjectAltnerativeName, then rootCA(Java)
SNOW - no longer need server certificate to be prestored in certificates<if failed, upload>, however, need to store CA(if not known CA)'s cert in system
servicenow/postman/java httpclient exception- bad cert, - no trust cert
this means client such as servicenow, postman failed to send out client cer to server
server side check
tls version aligns 1.2 - 1.2 1.2 above, for servicenow only supports 1.2 remove ciphers(algorthims)
servicenow compilance check:
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0789925
ServiceNow for mtls:
check protocl profile
keystore must be valid, if you are using crt +key using pk12
postman
settings -
check rootca cert is provided
check for ip and addr ca is supplied
https://superuser.com/questions/1336054/how-to-detect-if-a-network-is-blocking-outgoing-ports
Run this command to test a specific port (fast).
time nmap -p 22 portquiz.net
Run this command to test popular ports (slow).
time nmap portquiz.net
Run this command to test all ports (extremely slow).
time nmap -p- portquiz.net | grep -i open
To test if a given outgoing port is blocked on your network by some malicious middlebox, you can try to telnet into a server that has a service running on that port.
In this example, we use portquiz.net--which is a public service designed for this purpose. It uses iptables' nat table and has all tcp ports open.
# first we verify that we _can_ connect over port 443, which >99% of
# networks won't block; it works
user@personal:~$ time echo 'exit' | telnet portquiz.net 443
Trying 178.33.250.62...
Connected to portquiz.net.
Escape character is '^]'.
Connection closed by foreign host.
real 0m0.069s
user 0m0.002s
sys 0m0.043s
user@personal:~$
# next we try to connect over a port that's suspected of being blocked; it fails
user@personal:~$ time echo 'exit' | telnet portquiz.net 22
Trying 178.33.250.62...
telnet: Unable to connect to remote host: Connection timed out
real 2m10.635s
user 0m0.004s
sys 0m0.035s
user@personal:~$
Note that the first command exited immediately with the message Connected to portquiz.net, which indicates that the outgoing port 443 is not being blocked by the network.
The second command, however, says Unable to connect to remote host: Connection timed out. This shows that--unless there's an issue at portquiz.net--the outgoing port 22 is probably being blocked on your network.
You can take this a step further using nmap to get a list of all the ports that are not blocked by the network. For example:
user@personal:~$ time nmap -p- portquiz.net | grep -i open
21/tcp open ftp
53/tcp open domain
80/tcp open http
143/tcp open imap
443/tcp open https
465/tcp open smtps
587/tcp open submission
993/tcp open imaps
1935/tcp open rtmp
4070/tcp open unknown
real 3m48.324s
user 0m18.885s
sys 0m29.077s
user@personal:~$
In the above command, we can see that all outgoing ports are blocked except 21, 53, 80, 143, 443, 465, 587, 993, 1935, and 4070. In a normal/uncensored network, this list would be much, much longer (probably showing all 65535 ports)
nmap state:
The state is either open, filtered, closed, or unfiltered. Open means that an application on the target machine is listening for connections/packets on that port. Filtered means that a firewall, filter, or other network obstacle is blocking the port so that Nmap cannot tell whether it is open or closed
https://wiki.onap.org/display/DW/Nmap#:~:text=The%20state%20is%20either%20open,it%20is%20open%20or%20closed.