Tag: client

Decrypt DTLS traffic when using the Cisco AnyConnect Client

I am using the Cisco AnyConnect Client 4.7 to connect to a VPN. I need to decrypt the traffic to examine the packets and understand how VPN works. I have read about providing the PSK to Wireshark, but I can’t find somewhere explaining how to get that when using this Cisco Client.

Additionally, I need to do the same using the discontinued Cisco VPN client which supports IPsec. Again, I don’t know how to obtain the session keys to decrypt ESP traffic.

Just to make clear, I am not trying to perform an mitm attack, I have credentials and am connected to the VPN as a legitimate user.

Can I use the same truststore and keystore on the client and the server?

TL;DR: Is it possible to have both sides of a SSL/TLS connection have the same public and private key, so long as that public key is trusted by both sides?

More info if helpful:

I’m trying to test how I’d setup having Java application connecting to Kafka 2.1. I am using the same keystore and truststore for the Kafka cluster and the Java application, meaning both sides of the connection have the same public and private key. I understand this is not good practice, I just wanted to verify I understood how to configure things.

I can set 

listeners=PLAINTEXT://localhost:9092,SSL://localhost:9093 # This is the config style for 2.3 # listeners=HTTP://localhost:9092,HTTPS://localhost:9093 ssl.keystore.location=/path/to/kafka.keystore.jks ssl.keystore.password=test  ssl.truststore.location: /path/to/kafka.truststore.jks ssl.truststore.password: test  ssl.key.password=test

a bunch of properties in Kafka to enable TLS/SSL authentication. I feel confident that I’ve made the truststore and keystore correctly, where the truststore contains the 1 public key that the java side and the kafka side are using. I’ve done the same on the java side, roughly following a GitHub example.

I can’t get any connection going, and I am trying to remove possibilities for why. Could this be because both sides of the connection have the same public and private key?

Can you restrict the services a certificate can access on the client side?

I have a verification certificate signed by my organisation’s CA, which I can use to authenticate my user account on intranet web services.

Is there someway I can sign a new certificate which can only authenticate to one specific web service. Or some other way to enable limited access to one web service by a script I don’t want to give full access to my verification certificate.

Unfortunately I don’t have access to modify the web service, which is running nginx.

TLS 1.2. Handshake: Where do Client and Server negotiate how the master key is built from randoms and pre?

I am currently trying to solve an exercise where I should look at a TLS 1.2 handshake trace while having access to pre and both randoms (server random and client random).

In order to decrypt application data, I need to rebuild the master key.

But I am struggling with finding the section where it is negotiated how this master key is actually built from pre and randoms.

How does TLS 1.2 handle that? Is there maybe a default handling?

TLS 1.2 Handshake: Does the server have to take all extensions sent by the Client?

I am unsure about how extensions are handled in TLS v1.2.

During the handshake, the client is able to add some extensions during ClientHello. As far I understood, the server can pick arbitrary subsets from this list in ServerHello similar to picking the cipher suite, which the client provided during ClientHello. Is this correct?

If not, is it that the server can either take all those extensions into account, or must abort the handshake? I am not sure which is true.

I was looking for an adequate answer here in RFC5246, but didn’t really find the one statement I am looking for.

Client Certificates from Public Certificate Authorities

I’m looking into mutual TLS authentication for a B2B API. Is it possible to use mutual TLS authentication using X.509 certificates while relying on Public CAs?

I see that some Public CAs (from CA/Browser Forum) offer signed “client authentication” certificates. What fields can I rely on in this case? Would I be able to just map the Subject Name to a user in my application and trust the CA/Browser bundle?

Can “Public CA 1” guarantee that “Public CA 2” will not sell the exact same certificate to a different company?

Preventing XSS by filtering data from the server to the client

Before you immediately comment “you can’t trust the client!”, please read the whole question.

I’ve been reading about how to prevent XSS attacks lately, and everything I’ve found says that the server should sanitize the data that will be put into the webpage. This would basically look like addToDatabase(filter(userResponse)). Then the client can safely add display anything that it gets from the server.

I was wondering if it would be safe to store the potentially unsafe data in the server, and have the client filter it when it was received, like addHTML(filter(serverResponse)). This would stop the data from being executed client-side, so no XSS would take place. I understand that anyone could simply remove that filter, however all that would do is make themselves vulnerable. Since other clients would filter anything sent to them, a malicious client could could only disable their own filter and mess up themselves. (I’m not talking about SQL injection prevention, that would be obviously have to be server-side)

To summarize: The server doesn’t sanitize, but the clients sanitize whatever they receive.

Would this be safe?

Why server side hashing is required if the client side hashing is already in place?

I am looking for best practice for username/password login. People have different views for client side hashing on password.

From Google’s recommendation https://cloud.google.com/solutions/modern-password-security-for-system-designers.pdf

The client side hashing should be implemented as below:

Have the client computer hash the password using a cryptographically secure algorithm and a unique salt provided by the server. When the password is received by the server, hash it again with a different salt that is unknown to the client. Be sure to store both salts securely.

My questions are

  1. I agree the server should send a (unique) salt to the client. But why does the server need to hash the client result again with another salt?

  2. Does the above mechanism suggest the server should store both salts as separate columns in the database table? And assume both salts are static (not changed per each login?)

  3. SSL/TLS have mechanism to avoid replay attack. Does the above mechanism provide extra value to counter replay attack? I don’t see any random factor about the static salts and I cannot relate anything can address replay attack.