Why doesn't Firefox, nor its rebrands or forks, offer support for TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 {0xC0,0x30}, nor TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 {0xC0,0x2C}?
https://tools.ietf.org/html/rfc5289
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
>>53410722
this is far too advanced for this board.
pepper your angus for some trolling.
>>53410722
because you are not running gentoo GNU/linux.
windows dont have the required dependencies for those two since they are GPLv3 which microsoft have problems with, they prefer v2...
anyway, installing gentoo will fix your problem m8
>>53410798
you are wrong, firefox dropped its support in windows and not that windows lack the dependencies required for that, and gentoo wont fix it either, the last supported OS is Dos...
which can be advanced for some user but your TLS should run fine :)
>>53410755
no its not senpai..
some of us here knows their shit, so please kill yourself! thankyou
about op: install gentoo, it will fix that for you
>>53410798
>>53410834
>>53410857
The GPL, regardless of version, doesn't have anything to do with IETF RFCs, nor IANA. The GPL only concerns itself with offering open source licences of implementations that may or may not follow proposed standards. Installing Gentoo has nothing to do with this.
>>53410834
what the fuck about the trolling
gentoo dont have TLS_ECDHE* support you fuck!
debian with the new release have supported it while gentoo and windows dropped it two years ago
maceffing kill yourself
>>53410865
>IETF RFCs, nor IANA.
are you serious nigga? IETF RFC and IANA is directly related to v3... the section a)13 second line clearly states that... do you even read bro?
>>53410877
An operating system itself doesn't support TLS without a TLS library. Gentoo, as well as all other operating systems other than Linux all have support for TLS library implementations (e.g. OpenSSL, GnuTLS, et cetera).
In other words, this concerns library implementations, not operating systems.
>>53410905
It does not. There's no such section that refers to the GPLv3. Please stop trolling.
i should waste my life doing something else maybe something productive, well fuck, i just failed driver license test... anyway, GNU will save you op...
>someone kill me please
I'm just wondering why Firefox, nor its derivatives, don't offer these specific TLS cipher suites. Please refrain from posting meaningless messages if you have nothing to contribute to this thread.
>>53411032
I dont see how this will happen at all.
Vista is far more powerful than windows XP, and runs twice as fast. It is also much harder to pirate, and this point more than anything else has the Linux crowd in a panic.
It wont be long until Windows XP is no longer supported, and when that happens, what is Linux going to do ?
Linux will have to find a way to work under Vista from here on, since it wont be able to rely on XP being readily available anymore.
Linux may seem like a good alternative to Office, but all that is happening in linux is that the windows interface is cleverly hidden away. It still needs the drivers and software services in order to run, and in most cases - that happens WITHOUT a valid windows licence.
This is just plain piracy.
Vista will finally put an end to this blatant abuse of intellectual property, and linux should decline, taking the pirates with it.
Anyone that supports the continuation of Windows XP in place of Vista surely has a hidden agenda .. and you will surely be caught out.
>>53411032
did you not fucking read my warning: >>53410755
>>53411061
I did, but I didn't want to believe it. Perhaps I should've fucking known better.
/g/ fails to deliver again.
>>53411111
nice quints.
Also, this board is infested by millennials more interested in generals and headphone threads than anything else.
I suggest you ask Mozilla the question because I myself don't know either why some shit is omitted from Firefox. Honestly, I'm very confused about Firefox's general direction as is anyway without wondering about specific ciphers that they may or may not include
>>53411164
>I suggest you ask Mozilla
Thanks, I'll do that.
>>53410722
reading an older bugreport about other suites it states the NSS needs to implement it first, for them to use
wherever your os-nss has it implemented i dont know
using
https://www.ssllabs.com/ssltest/viewMyClient.html
on latest chromium build doesnt list it either, may related to the nss of my windows 7 build
>>53411284
This was helpful. I believe I found the bug report you referred to: https://bugzilla.mozilla.org/show_bug.cgi?id=975832
After installing Chromium as well I also found that they, like Firefox, also don't support these cipher suites with the current TLS library on my system.
I guess we'll just have to wait for it to be implemented, if NSS wants to be TLS 1.3 compliant when the proposed standard releases. The current draft suggests it will be part of the proposed standard here: https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-8
>>53410722
you got that pic on /v/ didn't you?
>>53414219
No, here.
>>53410722
Lack of SHA-384 exposed in the NSS backend. It's an annoying size, and NSS is an annoying library. They've been focused on more important tasks, like turning RC4 the fuck off, DH size limits, and MD5 and SHA-1 deprecation.
TLS_ECDHE_(RSA|ECDSA)_WITH_AES_128_GCM_SHA256 works OK.
You're more likely to see 0xCCA8 (TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256) and 0xCCA9 (TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256) support first - which is the final draft version.
I gather the vague plan is to add 0xC02C along with EdDSA (Curve25519|Ed448-Goldilocks) support (which uses the ECDSA ciphersuites, at least, that's the current plan - it's still waiting on CFRG last calls and so forth but all the discussion is basically done). X25519 and Ed25519 is exactly as specified by djb. Goldilocks, needing a larger fullwidth hash, uses Keccak as an XOF: specifically, SHAKE256.
NSS lags behind a bit there. Google's BoringSSL already has the 256 GCM and the new ChaCha final construct, so does LibreSSL and OpenSSL 1.1.0-dev (which also got X25519 ECDHE support).
Why SHA-384, you ask? NSA would have specified secp384r1/AES-192/SHA-384 as Suite B for the higher level if they could have, but literally nobody implemented AES-192 so they went with AES-256. But still, why not secp521r1/AES-256/SHA-512? Because SHA-512 isn't quite big enough for secp521r1 without expansion and that would have made it awkward.
There's also the issue that every time they change the TLS client profile of Firefox, someone needs to think about how Tor presents its TLS client profile (because Firefox is what it pretends to be, at least in theory - in practice, it fails at that to the point where pluggable transports were needed).
>>53416227
>Lack of SHA-384 exposed in the NSS backend. It's an annoying size, and NSS is an annoying library. They've been focused on more important tasks, like turning RC4 the fuck off, DH size limits, and MD5 and SHA-1 deprecation.
I figured as much, but these tasks are very important indeed, so what makes NSS so annoying?
>TLS_ECDHE_(RSA|ECDSA)_WITH_AES_128_GCM_SHA256 works OK.
Yes, I'm using it for lack of the stronger cipher suites.
>You're more likely to see 0xCCA8 (TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256) and 0xCCA9 (TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256) support first - which is the final draft version.
Sounds interesting, but I need to read up on Bernstein's ChaCha20 and Poly1305. How does it compare to AES-256 GCM?
>I gather the vague plan is to add 0xC02C along with EdDSA (Curve25519|Ed448-Goldilocks) support (which uses the ECDSA ciphersuites, at least, that's the current plan - it's still waiting on CFRG last calls and so forth but all the discussion is basically done). X25519 and Ed25519 is exactly as specified by djb. Goldilocks, needing a larger fullwidth hash, uses Keccak as an XOF: specifically, SHAKE256.
Is there a mailing list to subscribe to?
>NSS lags behind a bit there. Google's BoringSSL already has the 256 GCM and the new ChaCha final construct, so does LibreSSL and OpenSSL 1.1.0-dev (which also got X25519 ECDHE support).
Yes exactly, so why is NSS lacking behind? To few developers?
>Why SHA-384, you ask? NSA would have specified secp384r1/AES-192/SHA-384 as Suite B for the higher level if they could have, but literally nobody implemented AES-192 so they went with AES-256. But still, why not secp521r1/AES-256/SHA-512? Because SHA-512 isn't quite big enough for secp521r1 without expansion and that would have made it awkward.
That makes sense. Should I go for secp384r1 for servers in the mean time?
