"up to 65535 per SSL protocol" #138
Comments
|
When go down to the wire and look at the communication there, a "cipher suite" is nothing else than 2 bytes = 2^16 = 65536 |
|
Ah ok I see that's great. Yes I asked for fuzzing. |
|
;-) Remember, if you have a server in your barn which didn't get updates since ages, your modern openssl, rusttls, whatever, ... on your client can't check old ciphers, even the server enabled them. Be happy and feel safe with modern devsecops, continuous hourly updates, ... your security in the barn may be broken, and you won't see it. That's why I'm highly interested to get "your" panic error fixed. |
|
Ok. I currently have a network problem. When the network is repaired I'll give you what you need to debug the panic error. |
|
Hello, You said regarding cipher suite that "depending on the protocol it's actually 3 bytes". However, I didn't find a SSL/TLS version protocol having 3 bytes for the cipher suite, but If found for them all 2 bytes. Please to which SSL/TLS version protocol are you referring when talking about 3 bytes ? Thanks. |
|
SSLv2, for example |
|
But there's only SSL2, right ? Concerning I don't have the ancient openssl 0.9x, if you have it, could you paste the result of the command ? otherwise I'll have to try to download and install it on my hardened machine. |
AFAIK yes
see usr/install_openssl.sh |
|
Ok. Thanks. Therefore, it doesn't make sense to do a --range=full on a protocol that is not SSLv2, and thus we shouldn't do it. And do we agree that the --range=full mode is the best to test all the cipher suite possible of SSLv2 ? |
|
hmm, please make yourself used to the defined ranges first: Then you see that --range=full does not cover 3-byte SSLv2 ciphers. For testing SSLv2, I'd (currently) recommend --range=SSLv2 . However, this brings up other test cases for me, I'll think about more ranges ...
hmm, why? |
I broke the help option, cf. here.
Does this means that a cipher suite from the full range could be used by SSLv2 ? If it means that, then why the full range couldn't be used for SSLv2 ? It would make sense to use this range with SSLv2 if SSLv2 could accept a cipher suite from this range. No ?
Got it. The huge range mode will test all RFC defined possible combination for cipher suite id encoded on 2 bytes, meaning that if a SSL/TLS server is merely "correctly" configured (meaning as defined in the RFC), then ONLY the "huge" range mode has to be used to perfectly know which cipher suite (for a protocol version which is different than SSLv2) is accepted by the server. |
yes (see range=SSLv2)
I wrote "doesn't make sense" and not "couldn't be used". You can use any range for any protocol. It's just the special 2-byte cipher suites which will not work with other protocols.
yes, this could be tested.
yes
As long as the basic protocol (the first 3-way handshake) is SSL/TLS as defined in the standards, then it could be tested with o-saft. Any other "own implementation" is hard to test, this goes more in the direction of fuzzzing the protocol. That's the domain of other tools like TLS-attacker.
the sense of each range is what the user, who uses it, has in mind;-) |
|
Hmm.. so to fully test SSLv2 we should do the SSLv2 range mode plus the full range mode, right (I'm not very familiar with SSLv2) ? I don't understand also why the full range mode starts at 0x03000000 ad not 0x00 and why it ends at 0x03FFFFFF and not 0xFFFFFF ? Why is there this 0x03 before the 24 bits? |
|
Hmm, do you want to participate in the project?
because we distinguish SSLv2 and later protocols and ciphers according this byte (borrowed from SSL/TLS protocol, see all corresponding RFCs;-) |
I cannot now.
Would you know where I could find it easily ? Or maybe you meant "The answer will be in the code"?
Ok. |
Hi.
Could you explain please how you have "up to 65535" cipher suites "per SSL protocol" ?
I personally doesn't know any other cipher suite than those 376 ones.
Thanks.
The text was updated successfully, but these errors were encountered: