tls-n / nss-tlsn Goto Github PK

Mozilla's NSS library with TLS-N implementation.

License: Mozilla Public License 2.0

Shell 2.43% Makefile 1.62% Batchfile 0.01% Python 1.95% JavaScript 0.08% C 70.74% HTML 0.90% Java 0.07% Lex 0.02% C++ 15.91% Yacc 0.01% Perl 0.22% Roff 0.61% CMake 0.11% M4 0.11% Assembly 4.04% Ada 0.01% Perl 6 0.01% Objective-C 1.17%

tls-n nss

nss-tlsn's People

Contributors

Stargazers

Watchers

Forkers

sixteen anakornk cipherboy dnalob

nss-tlsn's Issues

No Network-Byte Order

nss-tlsn/nss/lib/ssl/tlsproof.c

Line 564 in c7a5845

    
           tlsproof_hash_op_nbo(PK11Context *ctx, const void* inbuf, const PRUint32 inbuf_len){

Extend ordering_vector_len to 32 bits.

nss-tlsn/nss/lib/ssl/tlsproof.h

Line 97 in 5730a7a

PRUint16 orderingVectorLen;

Padding computation must not be done anymore

nss-tlsn/nss/lib/ssl/tlsproof.c

Line 288 in 5730a7a

compressed_record_length += compute_compressed_record_padding(rpi);

How does this thing work? You have a struct ProofNode. It contains an enum called TLSProofNodeType, but its length is not specified. You copy its first byte on the proof string. How does the program know that the enum must be only one byte?

nss-tlsn/nss/lib/ssl/tlsproof.c

Line 1396 in 5730a7a

WRITE_LEN_AT_OFFSET(proof_str, proof_offset, &proofNode, PROOF_NODE_SIZE);

Implement stricter controls for the incoming messages. Also in the handle message request and handle message response functions.

nss-tlsn/nss/lib/ssl/tlsproof.c

Line 618 in 5730a7a

tlsproof_HandleMessage(sslSocket *ss, sslBuffer *origBuf)

Clarification requested: must server-side of an HTTPS session use specific TLS-N code?

It's not clear to me from your website and demo whether a server's TLS code must be modified, in order for a client to generate a non-repudiable proof of what the server said.

In particular, I used your "try it out" form to generate a proof of a HTTPS URL on twitter.com. (I don't expect Twitter's servers have been updated with your server-side code.) I then used your 'verify a proof' form to check the .PROOF file, and it showed the full conversation, client and server, as a 'valid proof'.

However, other credible sources (such as this Cryptography Stack Overflow answer) suggest there's not enough in a normal session to provide assurance a session transcript is authentic. (In particular, it says either party to the initial handshake could forge a transcript of both sides of the session.)

Can you clarify if your technique overcomes the TLS limitation even with only one side, such as the client with a non-upgraded server, generating the proof?

I think the size of this array must be set with realloc. If two consecutive nodes are hidden, in fact, one does not need to store both their hases, they can directly store the root hash of the subtree.

nss-tlsn/nss/lib/ssl/tlsproof.c

Line 1095 in 5730a7a

    
           rpi->proof_merkle_hashes = allocate_string_array(rpi->hash_size, rpi->num_hidden_chunks);

Should we return 0 here?

nss-tlsn/nss/lib/ssl/tlsproof.c

Line 1637 in 5730a7a

SSL_TRC(10, ("Error: Unknown TLSProof Type."));

Can this function be cancelled?

nss-tlsn/nss/lib/ssl/tlsproof.c

Line 1366 in 5730a7a

static PRUint32 recordPaddingSize(PRUint16 len_record, PRUint16 chunk_size){

Resizing allocation

nss-tlsn/nss/lib/ssl/tlsproof.c

Line 2326 in 5730a7a

    
           ss->tlsproofOrderingVector = PORT_Realloc(ss->tlsproofOrderingVector, ss->tlsproofOrderingVectorLen + 1);

It seems to me that the right allocation size should be ss->tlsproofOrderingVectorLen/8 +1 because ss->tlsproofOrderingVectorLen is the size in BIT of the ordering vector.

We saw that the function only works if the hash_size is exactly twice the salt_size. This is a note to remember to modify this function.

nss-tlsn/nss/lib/ssl/tlsproof.c

Line 720 in 5730a7a

    
           SECStatus my_hkdf_expand(RecordProofInfo* rpi, PRUint8* outbuf, PRUint8* inbuf){

Rename it to request the evidence

nss-tlsn/nss/lib/ssl/tlsproof.c

Line 678 in 5730a7a

SECStatus SSL_TLSProofRequestProof(PRFileDesc *fd)

The OrderingVectorLenIs reduced to 16 bytes, is it accidental or on purpose?

nss-tlsn/nss/lib/ssl/tlsproof.h

Line 97 in 5730a7a

PRUint16 orderingVectorLen;

Rename it to add message to evidence

nss-tlsn/nss/lib/ssl/tlsproof.c

Line 2201 in 5730a7a

    
           SECStatus tlsproof_addMessageToProof(sslSocket *ss, const PRUint8 *record, const PRUint16 record_length, PRBool received)

Since the evidence size can exceed the one of the packet, it might be sent in multiple packets. In that case, all the packet data must be put together, and then the handling function called.

nss-tlsn/nss/lib/ssl/ssl3con.c

Line 12855 in c7a5845

rv = tlsproof_HandleMessage(ss, databuf);

should it be renamed into num_normal_chunks?

nss-tlsn/nss/lib/ssl/tlsproof.c

Line 202 in 5730a7a

PRUint16 num_normal_records = 0;

I couldn't test it, but I think this is never freed

nss-tlsn/nss/lib/ssl/tlsproof.c

Line 206 in 5730a7a

PRUint8 *record = (PRUint8*) PORT_Alloc(rpi->record_length);

As far as I can understand, this structure qill be sent to the peer, but it uses a variable type which is typical of NSS. This might make it not compatible with other applications.

nss-tlsn/nss/lib/ssl/tlsproof.h

Lines 57 to 68 in 5730a7a

    
           #define PROOF_PAR_SIZE (sizeof(PRUint16) + sizeof(PRUint16) + sizeof(PRUint16) + sizeof(PRUint16) + sizeof(PRUint64) + sizeof(PRUint64)  + sizeof(PRUint16) + sizeof(PRUint16) + sizeof(SSLHashType)) 
        
           typedef struct ProofParStr{ 
        
           	PRUint16 hash_size; 
        
           	PRUint16 salt_size; 
        
           	PRUint16 chunk_size; 
        
           	PRUint16 num_proof_nodes; 
        
           	PRUint64 startTime; 
        
           	PRUint64 stopTime; 
        
           	PRUint16 sig_len; // Signature is directly after this struct 
        
           	PRUint16 cert_chain_len; // Certificate Chain is after the signature 
        
           	SSLHashType hash_type; 
        
           } ProofPar;

shouldn't a non existing chunk be considered non-sensitive?

nss-tlsn/nss/lib/ssl/tlsproof.c

Line 909 in 5730a7a

    
           right_nonsensitive = (rpi->salt_index+1 < rpi->num_chunks) && !is_hidden_chunk(rpi->hidden_chunk_ids, rpi->num_hidden_chunks, rpi->salt_index+1);

	#define PROOF_PAR_SIZE (sizeof(PRUint16) + sizeof(PRUint16) + sizeof(PRUint16) + sizeof(PRUint16) + sizeof(PRUint64) + sizeof(PRUint64) + sizeof(PRUint16) + sizeof(PRUint16) + sizeof(SSLHashType))
	typedef struct ProofParStr{
	PRUint16 hash_size;
	PRUint16 salt_size;
	PRUint16 chunk_size;
	PRUint16 num_proof_nodes;
	PRUint64 startTime;
	PRUint64 stopTime;
	PRUint16 sig_len; // Signature is directly after this struct
	PRUint16 cert_chain_len; // Certificate Chain is after the signature
	SSLHashType hash_type;
	} ProofPar;

tls-n / nss-tlsn Goto Github PK

nss-tlsn's People

Contributors

Stargazers

Watchers

Forkers

nss-tlsn's Issues

Recommend Projects

Recommend Topics

Recommend Org