Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is it possible to send SSL records in different tcp segments #78

Open
sajualways opened this issue Aug 17, 2020 · 10 comments
Open

Is it possible to send SSL records in different tcp segments #78

sajualways opened this issue Aug 17, 2020 · 10 comments

Comments

@sajualways
Copy link

I am looking for something like this

CKE handshake message in one tcp packet
CCS handshake message in one tcp packet
FIN handshake message in one tcp packet

@ic0ns
Copy link
Contributor

ic0ns commented Aug 17, 2020

This is fairly easy, you can just send the Messages in distinct actions, this will also send them in different TCP packets. If you want more complicated mixing it gets harder...

@sajualways
Copy link
Author

Got it......and what about if i need to send small record bytes i.e splitting the bytes across tcp segments or records

@ic0ns
Copy link
Contributor

ic0ns commented Aug 17, 2020

Splitting across records is also fairly easy, as you can also define the records in the workflow trace. This would look like this:

<Send>
        <messages>
            <ClientHello>
                <extensions>
                    <ECPointFormat/>
                    <EllipticCurves/>
                    <SignatureAndHashAlgorithmsExtension/>
                    <RenegotiationInfoExtension/>
                </extensions>
            </ClientHello>
        </messages>
        <records>
            <Record>
                <contentMessageType>HANDSHAKE</contentMessageType>
                <maxRecordLengthConfig>16</maxRecordLengthConfig>
                <computations/>
            </Record>
            <Record>
                <contentMessageType>HANDSHAKE</contentMessageType>
                <maxRecordLengthConfig>32</maxRecordLengthConfig>
                <computations/>
            </Record>
            <Record>
                <contentMessageType>HANDSHAKE</contentMessageType>
                <maxRecordLengthConfig>10000</maxRecordLengthConfig>
                <computations/>
            </Record>
        </records>
</Send>

This would send the client hello in 3 records, with 16,32 and the rest of the handshake bytes each. There are also flags in the config which change the default behavior of how tls-attacker fragments. Fragmenting on the TCP layer is harder, as we do not have a good interface for that. If you really want to do more complex tcp fragmetation you will probably need to write some code for it.

@sajualways
Copy link
Author

thanks......but what i was looking is for something like this----Client hello message Record header which is of 5 bytes header.
Out of this 5 bytes header, 3 bytes should go in one tcp packet and remaining 2 bytes header + client hello() message in second tcp packet

@ic0ns
Copy link
Contributor

ic0ns commented Aug 17, 2020

Ah i see, i dont think we have a flag or a good interface for that as of yet, but i think it can be easly added. You would need adjust the SendMessageHelper for this. It is not trivial to do - but also not super hard. It appears useful to me, so if you want I can put it on the todo-pile

@sajualways
Copy link
Author

yeah sure...it will be good if we have this feature enhancement.

@sajualways
Copy link
Author

sajualways commented Aug 17, 2020

what about this plainRecordBytes

Whether this can be used here?

@ic0ns
Copy link
Contributor

ic0ns commented Aug 17, 2020

With plainRecordBytes you can manually hack this together, but its not really useable. You could theoretically send the same message twice and use a byteArrayDeleteModification to first strip the end of the message and then strip the beginning of the message in the next record.

@sajualways
Copy link
Author

Ok fine...will wait for the proper Enhancement then.

Let me know once it is checked in.

@ic0ns
Copy link
Contributor

ic0ns commented Jun 8, 2022

We decided to put this into TLS-Attacker 4.0, which is a complete rework of the framework to properly implement this feature - will take some more time

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants