42

... change the public key in the certificate and send it to client. Digital signature is same, all the properties except public key are same. So how can browser understand the difference? The browser checks that the signature of the certificates fits the certificate. Since the public key is included in the signature and the public key is changed, the ...


25

At the end of the TLS negotiation (the "Finished" message), the client and the server take a hash of the entire conversation they've had so far, and they compare it. If it differs - as it would if someone performed a MitM attack on the certificate - then the connection is dropped. To quote RFC 5246: The Finished message is the first one protected with ...


24

Certificates don’t exist in isolation. To be trustworthy, a certificate must be signed by an issuer; these issuers are called Certificate Authorities. Each browser (or operating system) maintains their own list of a few hundred trusted CAs (called Root CAs) that it already knows and trusts; and your employer or school may have their own private issuing root ...


4

It looks like that the debug output is made on the client side. In this case 3, RECV TLSv1 ALERT: fatal, certificate_unknown means that the client received an TLS alert from the server which means that the server did not like the certificate the client has send, i.e. the client certificate: Validity: [From: Tue Aug 08 16:26:27 CDT 2017, To: ...


4

The SSL handshake includes random data from both client and server. While the attacker might replay the ClientHello which includes only the random data from the client he cannot complete the full handshake by just replaying previously captured data since the messages needed for completion also depend on the server side random data, which will change with ...


4

Can this be captured by an attacker? Yes - but its not much use to them. It's an indirect reference to the algorithms and keys previously (and securely) agreed, which are remembered by the server/client. So if the attacker asserts to your server that he wants to resume the session, your server will resume with ciphertext the attacker's client doesn't know ...


4

In theory it would be possible to do a 0-RTT handshake if the certificate is known up-front (like via DNS) and RSA key exchange is done. In RSA key exchange the client creates the full premaster secret (from which encryption key etc are derived) and sends it encrypted with the servers public key (from the RSA certificate) to the server. If simplifying RSA Kx ...


4

There are several uses of hash functions within the TLS handshake. Creating the master secret from the information exchanged in the key exchanged, see TLS 1.2 section 8.1. This is not using the hash function directly but a PRF (pseudo-random function) is created using hashes (see section 5). Similar the key material used for symmetric encryption and HMAC is ...


4

From RFC 8446, Section 5 (TLS 1.3, Record Protocol): The TLS record protocol takes messages to be transmitted, fragments the data into manageable blocks, protects the records, and transmits the result. Received data is verified, decrypted, reassembled, and then delivered to higher-level clients. The cipher for encrypting fragments at the Record ...


4

Due to backwards compatibility concerns, TLS uses a fake TLS version number in the record layer. struct { ContentType type; ProtocolVersion legacy_record_version; uint16 length; opaque fragment[TLSPlaintext.length]; } TLSPlaintext; legacy_record_version: MUST be set to 0x0303 for all records generated by ...


3

While a C&C client would hide its real target by not using SNI it would be suspicious especially because it does not use SNI with HTTPS while everybody else does. It might be better then to claim that it connects to some innocent target by setting the SNI extension accordingly but in reality connecting to the C&C server. This only needs some fiddling ...


3

I think the key is to realize the difference between acceptability and preferences. Each side has a set of accepted ciphersuites, and a preference order among those ciphersuites. Non-accepted ciphersuites aren't considered for preferences at all. Due to the design of the TLS protocol, the client sends its set of accepted ciphersuites to the server. It sends ...


3

Within TLS the client sends a list of supported ciphers in the order of their preference by the client. The server has its own lists of ciphers it is willing to support. The server is free to choose any of the ciphers the client offers and which are also supported on the server side. How this choice is done is not specified. To keep the choice simple the ...


3

Yes, each extension defines what it means. A server that has never heard about this extension (e.g. the server is old and the extension is new) just disregards it, and the client must be ready to deal with that (at worst, by breaking the connection after ServerHello, but usually by falling back to the behavior before the extension was defined). The ...


2

That said, RSA handshake consists, in fact, in an exchange of public keys, followed by a secured exchange of an AES key, which is then used to encrypt all communications without any length cap. So RSA based exchange is only used at the handshake moment. There is no RSA handshake but a TLS handshake. And there is usually no (bidirectional) exchange of public ...


2

A) Decide on doing client certificate authentication based on the hostname This can be done even if both domains are served on the same IP address as long as the browser sends the target hostname within the SNI TLS extension. All modern browsers do this by default and most but not all apps on recent mobile systems. B) Decide on doing client certificate ...


2

Usually it takes only few seconds.however, if you're using the card on a virtual machine you might face problems. I can confirm that the card works (i tried it myself). first time was with Backtrack-5 live boot CD and it worked perfectly, next time was on virtual Kali 2.0 and it didn't work. Just as you described it, the deauth packet goes and nothing ...


2

"Client" and "server" can be vague terms if multiple layers (TCP, TLS) are involved. It is possible and even the most common case that only a single certificate is used inside the TLS handshake, i.e. one party is properly authenticated in order to detect man in the middle attacks. This party is commonly the TCP server but it might also be the TCP client. If ...


2

For TLS through 1.2 in most cases (see below) using DHE key exchange, the DH group (prime p and generator g of suitable subgroup of Z_p^*) is sent by the server; the client has no influence beyond specifying a list of ciphersuites that does or does not lead the server to select a ciphersuite that uses DHE (at all). In general server software (or firmware, ...


2

My confusion stems from reading that TLS handshake uses some kind of Diffie Hellmann, when I was certain that the symmetric key was generated by a digest of earlier packets encrypted with clients public key and safely decrypted with servers PK. The key exchange is used to generate the symmetric key (or at least the pre-master secret which the keys are ...


2

You are assuming that some error can occur which makes it impossible for the client to compute the keys correctly. Assuming that client and server have completed the handshake so far in a correct way, so that the input data for computation of the keys are available at the client and they are correct. Also, assuming that there are no implementation errors. In ...


2

Nothing really is known about your client and the screenshots don't provide enough information about the ClientHello send by the client. But the typical cause of this problem is that your client does not use Server Name Indication. SNI includes the expected target domain in the ClientHello and is needed if multiple domains with different certificates are ...


2

Will the client/server completes is certificate chain using trusted certs and extra certs? Yes, SSL_CTX_use_certificate will load the certificate and SSL_CTX_add_extra_chain_cert will load the chain certificates and both are sent to the peer during the TLS handshake. During SSLHandshake what shall the peer present? Only the domain certificate or the ...


1

The "misbehaving" pcap has a capture for HTTP proxy traffic on port 443, i.e. a HTTPS traffic prefixed by a HTTP CONNECT request and response. Port 443 is reserved for direct HTTPS though and not for proxied HTTPS. It looks like Wireshark somehow insists that it should be either direct HTTPS on this port (which is how the port is commonly used) or that it ...


1

That depends on the scenario, and what kind of information you are worried about. In order to make the following examples less cluttered, I will always be calling the access point "AP" and the client device "Client". AP Broadcasts, Client does not want to connect Depending on how the client is set up, it is possible that the client regularly sends out ...


1

TLS has two extensions, NPN and ALPN (spec), which allow the client to say that it wants to use something other than plain HTTP/1.1 when it finishes handshaking. NPN is older and was deprecated in favor of ALPN. The recommended way to use HTTP2 over TLS is to ask for it using ALPN and get a reply from the server that you can use it, and then you can ...


1

TLS 1.2 > http/1.1 TLS 1.2 > h2 ... What do these things mean? Both indicate that TLS 1.2 was supported. One indicates that the underlying HTTP protocol was HTTP/1.1, and the other indicates that the underlying HTTP protocol was HTTP/2.


1

Since you have written that you captured the handshake.The next logical step is to bruteforce the cap file that you obtained at the handshake part.For that use the following command aircrack-ng capfile -w wordlistfile ofcourse change the capfile to the name of your cap file and your own wordlist P.s:- You should really google first before asking


1

My question came from that little phrase "WPA key length". What does that phrase mean? It appears to mean the length of the WPA key in bytes. The "WPA Key" element is displayed in your figure right below the "WPA Key Length" element. The "WPA Key" appears in your figure as a string of 48 ASCII characters representing a sequence of 24 bytes. E.g., "DD" ...


1

Although I am still interested in any additional information the community can provide I am happy to report that the issue has been mitigated through a client modification. I'm using OpenSIPs 2.3 which provides TLS via a module tls_mgm. This module has a setting for handshake timeout which defaults to 30 although I am running with 60. The docs state that ...


Only top voted, non community-wiki answers of a minimum length are eligible