Asked  7 Months ago    Answers:  5   Viewed   24 times

Are all URLs encrypted when using TLS/SSL (HTTPS) encryption? I would like to know because I want all URL data to be hidden when using TLS/SSL (HTTPS).

If TLS/SSL gives you total URL encryption then I don't have to worry about hiding confidential information from URLs.



Yes, the SSL connection is between the TCP layer and the HTTP layer. The client and server first establish a secure encrypted TCP connection (via the SSL/TLS protocol) and then the client will send the HTTP request (GET, POST, DELETE...) over that encrypted TCP connection.

Tuesday, June 1, 2021
answered 7 Months ago

The whole lot is encrypted - all the headers. That's why SSL on vhosts doesn't work too well - you need a dedicated IP address because the Host header is encrypted.

The Server Name Identification (SNI) standard means that the hostname may not be encrypted if you're using TLS. Also, whether you're using SNI or not, the TCP and IP headers are never encrypted. (If they were, your packets would not be routable.)

Friday, June 4, 2021
answered 6 Months ago

Pretty much all* browsers will support 4096-bit keys. The issue you'll run into is that key exchange is slower with larger keys, which will increase load on the server and slow down page loading on the client.

2048-bit keys are generally considered safe for the time being. If you want an intermediate step, though, 3072-bit keys are right smack-dab in the middle.

*: Only exception might be a couple of weird, old mobile / embedded browsers.

Sunday, August 1, 2021
Georges Dupret
answered 4 Months ago

I am currently using a self created self-signed certificate in development environment. ... No name matching found

It appears the self signed certificate is incorrect.

Below is the OpenSSL CONF file I use to create self signed certificates and certificate requests to use during testing. Save it as example-com.conf. Change the DNS names under [ alternate_names ] to suit your tastes. You can even put localhost, localhost.localdomain and in there for testing.

If you want to create a self signed certificate, then use:

openssl req -config example-com.conf -new -x509 -newkey rsa:2048 
    -nodes -keyout example-com.key.pem -days 365 -out example-com.cert.pem

If you want to create a signing request (CSR) that will be signed by a trusted authority, then use:

openssl req -config example-com.conf -new -newkey rsa:2048 
    -nodes -keyout example-com.key.pem -days 365 -out example-com.req.pem

The difference between a self signed certificate and a signing request is the -x509 option. With -x509 present, a self signed certificate is created. The absence of -x509 means a request is created.

If you want to print your self signed certificate or request to see what's actually in it, then use:

openssl x509 -in example-com.cert.pem -text -noout
openssl req -in example-com.req.pem -text -noout

If you want to test the server, then use s_client:

openssl s_client -connect <server>:<port> -CAfile <trust-anchor.pem>

The above command should finish with a message similar to Verify OK (0). If you don't receive Verify OK (0), then fix your test rig. Once OpenSSL completes successfully, then that becomes your baseline.

[ req ]
default_bits        = 2048
default_keyfile     = server-key.pem
distinguished_name  = subject
req_extensions      = req_extensions
x509_extensions     = cert_extensions
string_mask         = utf8only

[ subject ]
countryName         = Country Name (2 letter code)
countryName_default     = US

stateOrProvinceName     = State or Province Name (full name)
stateOrProvinceName_default = NY

localityName            = Locality Name (eg, city)
localityName_default        = New York

organizationName         = Organization Name (eg, company)
organizationName_default    = Example, LLC

# Use a friendly name here. Its presented to the user.
#   The server's DNS name show up in Subject Alternate Names. Plus, 
#   DNS names here is deprecated by both IETF and CA/Browser Forums.
commonName          = Common Name (e.g. server FQDN or YOUR name)
commonName_default      = Example Company

emailAddress            = Email Address
emailAddress_default        =

[ cert_extensions ]

subjectKeyIdentifier        = hash
authorityKeyIdentifier  = keyid,issuer

basicConstraints        = CA:FALSE
keyUsage            = digitalSignature, keyEncipherment
# extendedKeyUsage  = serverAuth
subjectAltName          = @alternate_names
nsComment           = "OpenSSL Generated Certificate"

[ req_extensions ]

subjectKeyIdentifier        = hash

basicConstraints        = CA:FALSE
keyUsage            = digitalSignature, keyEncipherment
# extendedKeyUsage  = serverAuth
subjectAltName          = @alternate_names
nsComment           = "OpenSSL Generated Certificate"

[ alternate_names ]

DNS.1       =
DNS.2       =
DNS.3       =
DNS.4       =

# Add these if you need them. But usually you don't want them or
#   need them in production. You may need them for development.
# DNS.5       = localhost
# DNS.6       = localhost.localdomain
# DNS.7       =

Is it OK to skip SSL verification ?

No. That's very irresponsible. If you are not going to use PKIX correctly, then why use it at all?

This comes to mind: The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software.

HostnameVerifier allHostsValid = new HostnameVerifier() {
    public boolean verify(String hostname, SSLSession session) {
        return true;

Its better to load your self signed certificate in a Keystore (or load your private CA), and then pass it to SSLContext.init. Then everything works as intended, and there's no need to trust everything or return true from verify.

Bruno and EJP have plenty of answers covering that subject.

What are the other alternate way to achieve a common solution for both development and production environment?

Use a well formed certificate that chains back to a trusted root.

For testing, you can create a self signed certificate. Or, create a certificate request and have it signed by your internal CA in a private PKI. In this case, you need to trust your self signed certificate or trust your internal CA.

For production, you can use a certificate signed by one of the members of the CA Zoo so others outside the organization trusts it too. StartCom and CACert offer free Class 1 certificates.

Class 1 certificates are usually domain validated and don't allow wild cards. While the Class 1 is issued for free, they charge for revocation because that's where the cost lies.

If you need a wild card, then you will usually to purchase a Class 2 or higher.

Monday, August 9, 2021
Jeff Swensen
answered 4 Months ago

IE issues a CONNECT request to my proxy My proxy sees that its a CONNECT request and gets the ip:port of the destination (eg, My proxy creates a new TCP connection to

All correct so far.

My proxy gets an SslStream from this destination and calls AuthenticateAsClient - this gives my proxy a secure connection to the hotmail side of things

No. Your proxy should use the plain-text connection you already have.

My proxy then sends an "HTTP/1.0 200" message back to the browser to say that the CONNECT was successful.

Correct. Or else if you got a connection failure you send back an appropriate HTTP failure response.

My proxy then gets an SslStream from the browser connection and calls AuthenticateAsServer - gives my proxy a secure connection to the browser side of things

No. Your proxy continues to use the plaintext connection to the browser.

how AuthenticateAsServer without fake certificate?

You don't have to do it at all.

At this point the browser and the upstream server are ready to execute the SSL handshake. But as you said you don't want to sniff the contents, you have no need to be an SSL endpoint yourself. All you have to do now is copy bytes in both directions simultaneously. The endpoints will SSL-handshake just as though you weren't there.

Wednesday, August 18, 2021
answered 4 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :