5

This depends on the tool you are using within Burp: Site map - HTTP and HTTPS URLs are shown separately in the tree Proxy - There is an SSL tick box in the table Repeater - The target URL will show HTTP or HTTPS Logger++ There is an SSL tick box similar to Proxy Burp does not show the SSL cipher suite used. You can use the SSL Scanner extension in the BApp ...


4

Blocking a port is cheap: it can be done by a simple stateless firewall only inspecting up to OSI layer 4. It can also be done with the first packet already, i.e. even at the TCP handshake were no data are transferred yet. Blocking by the actually spoken application protocol needs to analyze the payload (layer 7). This means that first it needs to collect ...


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 ...


2

Came across this old question. If you are still looking for answers, found the following https://pykmip.readthedocs.io/en/latest/index.html : This one seems to be actively developed. https://www.ibm.com/developerworks/library/se-kmip4j/index.html : Didn't see much activity here.


2

Basically, Lucky13 happened, and the results were very bad: Amazon s2n thought they fixed it, but turns out they didn't. OpenSSL introduced a much worse vulnerability when they tried to fix it. Google's Adam Langley, possibly the best TLS implementer in the world, chose to not implement the fix in the Go standard library's TLS implementation and recommended ...


2

Yes, this would be a message authentication code or MAC. It is a cryptographic hash that only the parties that have the secret key can compute. Party A computes the MAC over the message. Party A sends the MAC and the message to party B. Party B computes the MAC over the message. Party B now compares the computed MAC to the actual MAC, and knows whether the ...


2

Disclaimer: this is an answer for why this question is too broad. I am not attempting to actually answer the question because that would be, well, too broad. In comments, you said: I think that my question really belongs here and not in cryptography section because it contains nothing about custom techniques and algorithms. The key exchange scheme I ...


2

It depends which generation of IDaaS you are referring to but in general Active Directory (and other IAM solutions) tend to have better support for on-prem authentication protocols than IDaaS, which is a cloud bridge, does. I find your question intriguing because I have never tried to compare them previously (they are after all apples and oranges). I have ...


2

how does this cipher work? Assuming you are talking about the classic (broken) algorithm, KeeLoq is a 528-round block cipher utilizing a 32-bit non-linear feedback shift register (NLFSR) and 64-bit circular shift register (the key register, initialized with the key data). It has a 32-bit block size and takes a 64-bit key. Below is a diagram of a single ...


2

ClientID and Client Secret are basically the same idea as a username and password, though keep in mind that in some contexts they could refer to different things. Either way you will generally use it to fill a basic authentication header in a HTTP request to the authorization server. Not using a ClientID is, to my knowledge, impossible. You are claiming an ...


1

As with everything, you engage the control that is proportionate to the risk. We can't really advise on the appropriate control without understanding more about the risks. These are a few processes that are commonly used: 3rd party review (be it professors, friends, or paid reviewers) threat modelling/vulnerability modelling (standard frameworks exist for ...


1

I think you're going to often find that your criteria is constrained by several factors, which actually limit what you can test. The tools you have access to, and the licences you're operating under (terms of service, DMCA, etc.) can limit the scope in some cases. Any fuzzing that requires destructive interfere with another user is probably out, as well as ...


1

Any mismatch gets rejected You don't have the ability to send your altered transaction details to the bank, only the merchant does that. The only thing that you influence is the signed message digest. Furthermore, the confidentiality is enforced by the fact that the message digest is a one-way operation - a 50 euro transaction has a different digest (and ...


1

The dual signature is encrypted with the customer's private key, so the banks can use the public key to decrypt it. The contents of the dual signature is a hash of the digest of the purchase order and the payment info, and anyone with both digests can reproduce that value. The merchant gets the purchase order and the digest of the payment information, so ...


1

Just from the simple description you give, two security flaws stand out. There may be further flaws in an actual implementation. The server needs to know Alice's key. This means the server, or anyone who compromises the server, can impersonate Alice. There's no server authentication. It may be possible for someone to impersonate a server and get Alice to ...


1

As shown below, the key is generated using p = ((riv XOR streamCtr) || inputCtr). It is required that "no two elementary streams contained in a given program or different programs can have the same streamCtr if those elementary streams share the same Ks or riv" in order that the streams will be encrypted with different keys (using different p). If an ...


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