tls – SNI leakage prevention with proxy

In TLS 1.2 / HTTP(S) context, plaintext target hostname could potentially leak in 3 different ways:

  • In DNS query prior to TCP/TLS/HTTPS connection.
  • In TLS handshake, ClientHello message, in SNI extension.
  • In HTTP Host header.

DNS leakage can be prevented by using e.g. DoH/DoT.
HTTP Host header leakage is prevented through TLS encryption.
This leaves us with SNI leakage to address.

Which proxy types prevent leaking plaintext SNI and how?

Please note I’m asking explicitly about proxies, not ESNI, domain fronting or other similar means.

domain name system – Error Hostname DOES NOT VERIFY – Test certificates TLS Exchange 2016 cu21

Practicing with the certificates, in let’s encrypt win-acme normal is created, I send and receive normal mail, https in owa and the other services

Testing with checktls, it gives me an alert message :

Cert Hostname DOES NOT VERIFY:

(mail.contoso.com != mail | DNS:mail | DNS:mail.lan.contoso.com)

I don’t understand the mail.lan.contoso.com DNS error.
I thought the error was the DNS SPLIT, but reading in the forum they comment on something about the error.

I understand that the other connectors should not be changed in forums, books and tutorials, nobody changes them. That is why a new connector is created to receive from the internet, to which the FQDN can be changed.

Recommendations of this forum, my dns settings :

Private AD DNS (lan.contoso.com)

Record Type DNS Name Internal IP
A mail.lan.contoso.com 192.168.1.4
A DC01.lan.contoso.com 192.168.1.3

Private DNS (contoso.com) SPLIT

Record Type DNS Name Internal IP
A mail.contoso.com 192.168.1.4
A autodiscover.contoso.com 192.168.1.4

Public DNS (contoso.com)

Record Type DNS Name Value
A mail.contoso.com xxx.xxx.xxx.xxx
A autodiscover.contoso.com xxx.xxx.xxx.xxx
MX @ mail.contoso.com

tls – Why can’t tls1.2 server use certificate’s private key to encrypt ‘server finish’, and send if after ‘server hello’?

The Server Finished message does not contain anything relevant. It’s merely a test/validation to ensure the Server has generated proper Session Keys.

By encrypting a hash of the transcript of the handshake and sending it to the Client, the Client is able to validate that the Server has the correct Session Keys, and that both the Client and Server “saw” the same handshake records.

The Client does the same in the opposite direction with the Client Finished.

If you changed this mechanism, you’d need to add another mechanism to validate the Server has the proper session keys.

And, having the Server encrypt it’s Certificate record to the Client would only serve one purpose: Proves the Server has the matching Private Key… but that is already proven because the Server signs it’s Server Key Exchange record.

So in the end, your suggestion would take away a necessary step, and add an unnecessary step.

tls – How to use the concept of private/public key and certificates in order for the server to be able to validate the client?

I understand how public/private key and certificate is used for SSL. A client sends request to server. Server responds with certificate (and its public key). Client validates certificate, creates a new key, encrypts it using servers public key and sends it to the server. Going forward the client and server communicate using this shared secret key.

The above ensures that the client is convinced that the server is genuine.

I want to learn about how this concept can be used for server to be convinced that client is a genuine.

Please can someone explain to me like paragraph 1, how this would work? For example – client when making a POST request should be able to validate the server using the concept I have mentioned in paragraph 1 and additionally the server must be able to validate the client. In this case, would the client also send certificate? And what would be the flow of the working be like?

19.10 – postfix cannot enable tls

I have been following https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-postfix-as-a-send-only-smtp-server-on-ubuntu-20-04.

Currently I’m able to send emails to less secured mailboxes, but not GMail. GMail requires encryption.

/etc/postfix/main.cf has the following content.

# TLS parameters
smtpd_tls_cert_file=/etc/letsencrypt/live/gqqnbig.me/fullchain.pem
smtpd_tls_key_file=/etc/letsencrypt/live/gqqnbig.me/privkey.pem
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

smtpd_tls_auth_only=yes
smtpd_tls_security_level=encrypt
smtp_tls_security_level=encrypt

postfix still doesn’t encrypt emails. I suspect postfix is not reading my keys. Therefore I made an experiment that I pointed smtpd_tls_cert_file to a non-existent path, and /var/log/mail.log does not report an error. Note here I added a 0 to the path.

~$ postconf | grep smtpd_tls_cert_file
smtpd_tls_cert_file = /etc/letsencrypt0/live/gqqnbig.me/fullchain.pem
tlsproxy_tls_cert_file = $smtpd_tls_cert_file

When smtpd_tls_cert_file points a non-existent path, do I expect to see an error message somewhere?

How do I configure postfix so that it encrypts email and sends to GMail?

amazon web services – Redirect TLS traffic by hostname

I have an IoT device that connects to a.iot.x.amazonaws.com at port 8883 (secure MQTT).
I would instead like it to connect to my own site at b.iot.x.amazonaws.com (same port and protocol). I would like to use network tools to redirect the traffic. I do not wish to replace the firmware on the IoT device. I am using a site on the same subdomain (iot.x) to avoid TLS issues, since the certificate AWS provides covers the whole iot.x subdomain.

My trouble is, I think both domains resolve to the same IP addresses, so I can’t simply use the hosts file in my OpenWRT router to redirect traffic. Shared hosting would mean that the site it connects to is determined by the domain name, not the IP address alone.

Is modifying the domain name during the connection request enough to accomplish this? Is there a tool available to do this?

Custom PKI for TLS in iOS vs. Android

An app on iOS has to perform an HTTPS connection, validating certificates against a root CA of a custom PKI.

Android seems to have best-practice procedures to handle this: one can ship the CA certificates with the app, and even configure pinning declaratively.

I haven’t been able to find a similar mechanism on iOS. All the material I could find suggests that TLS validations should pass through iOS, and that the CA certificate should be added to the Trust Store and therefore trusted at system level.

Question 1: have I missed something?

Question 2: in case I have not, I’m confused about the security model of iOS. Doesn’t forcing to trust certificate at system level imply a greater risk than just allowing developers to embed CA certificates in apps?
One attack scenario comes to mind: if I were able to distribute an app and convince users to trust my custom CA certificate to access my private cloud, then I could use my PKI to sign certificates for arbitrary domains, to be used in MITM attacks.

certificates – Is SNI always used in TLS connections?

I know the both DoT and DoH leak the target of the connection due to the use of SNI in the client hello (and that ESNI/ECH are proposed solutions), but what I cant figure out is does SNI get used 100% of the time (assuming a TLS connection)?

If it’s not 100% of the time, then when does it or doesn’t it get used?

  • by “used” I mean is it always present in the client hello making TLS connections ALWAYS leak their target

tls – With Network Security Systems Decrypting SSL traffic to scan for Malware Is Server-Side hashing of Credentials Still Enough?

I am not a Security Expert by any means. Nor am I a Cryptographer. That’s why I’m here.

After discovering that the server side of some software I work on was operating on plain text passwords (though I later determined that only the hash was stored in the database) I started researching into what parts along the way between the client and the server the password was in plain text.

To my surprise (I’m ignorant remember?) I discovered that I was able to view the password in plain text at every step in the process, client side debugging of javascript, packet inspection of network packets, and debugging the server log in code.

I, of course, had a heart attack. I couldn’t believe that the software I was working on would ever allow someone to read a password in plain text at any point after the login button was clicked. So I started researching the question.

First I determined that the network packets were indeed encrypted via SSL. I had implemented a MitM attack against myself using Fiddler to decrypt the packets. This eased my worries, but only for about 60 seconds. I then discovered a number of blog posts by security companies advising their readers to DECRYPT and INSPECT the SSL packets being sent across their networks. The reasoning being that even Malware can use SSL, and that it often does exactly that to hide from firewalls.

Here’s where I started to get concerned. You see, I don’t trust anything or anyone when it comes to security.

If a security administrator can decrypt my SSL packets on my corporate network, why can’t a bad actor working at my ISP do the same thing?

I started researching how passwords should be transmitted via HTTPS, and ran into an interesting debate, that is mostly settled, from the early days of HTTPS. This was the debate on Client-Side vs Server-Side hashing. Server-Side hashing makes perfect sense, and clearly wins in a situation where the network packet encryption is practically impenetrable, but once you have a company’s IT department decrypting those packets, is server-side hashing really the only thing we need?