mastodon.world is one of the many independent Mastodon servers you can use to participate in the fediverse.
Generic Mastodon server for anyone to use.

Server stats:

8.1K
active users

#ngtcp2

0 posts0 participants0 posts today
daniel:// stenberg://<p>Meanwhile in <a href="https://mastodon.social/tags/curl" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>curl</span></a> land, we can now do <a href="https://mastodon.social/tags/HTTP3" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>HTTP3</span></a> with <a href="https://mastodon.social/tags/ngtcp2" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ngtcp2</span></a> 1.12.0 and <a href="https://mastodon.social/tags/OpenSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OpenSSL</span></a> 3.5.</p><p>Thanks to lots of amazing people, including <span class="h-card" translate="no"><a href="https://chaos.social/@icing" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>icing</span></a></span> and Tatsuhiro of ngtcp2 of course.</p>
daniel:// stenberg://<p>It looks like the <a href="https://mastodon.social/tags/OpenSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OpenSSL</span></a> QUIC API might be supported in the coming <a href="https://mastodon.social/tags/ngtcp2" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ngtcp2</span></a> 1.12.0 release:</p><p><a href="https://github.com/ngtcp2/ngtcp2/pull/1582" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">github.com/ngtcp2/ngtcp2/pull/</span><span class="invisible">1582</span></a></p><p>This could be exciting for <a href="https://mastodon.social/tags/curl" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>curl</span></a> users building with <a href="https://mastodon.social/tags/OpenSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OpenSSL</span></a> ...</p>
ϺΛDИVTTΛH<p><span class="h-card" translate="no"><a href="https://fosstodon.org/@nlnetlabs" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>nlnetlabs</span></a></span> The build ain't as straightforward as we're used to. Why can't one just use <a href="https://fosstodon.org/tags/openssl" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>openssl</span></a> with <a href="https://fosstodon.org/tags/ngtcp2" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ngtcp2</span></a> but instead need <a href="https://fosstodon.org/tags/quictls" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>quictls</span></a>? I fear I sacrifice security by not using official OpenSSL libs for <a href="https://fosstodon.org/tags/quic" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>quic</span></a></p>
Petr Menšík :fedora:<p><span class="h-card" translate="no"><a href="https://mastodon.social/@bagder" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>bagder</span></a></span> quite interesting details about quic support. It affects also DNS over QUIC, not only HTTPS/3. At least unbound and bind9 are compiled with OpenSSL on Fedora. Unbound has added recently server support via <a href="https://fosstodon.org/tags/ngtcp2" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ngtcp2</span></a>. But it gets weird and inappropriate, linking two different crypto stacks into single binary. The reason is similar to curl. Normal TLS from OpenSSL, quic via gnutls. If it should be enabled, then this way...</p>

An #ngtcp2 lead developer told me they have no current plans to adapt to the new #OpenSSL #QUIC API because of its lack of 0RTT support and the "pull model".

Of course someone else can go ahead and write it and ideally someone from #OpenSSL does it, for dogfooding purposes.

I have no heard of any other QUIC stack either having adapted to it yet.

#OpenSSL #QUIC implementation performance is "abysmal" compared to competing solutions such as #ngtcp2 (ngtcp2 is 2-4x faster) and consumes tons (up to 25x in some situations) of memory. (*)

I still don't fathom why the OpenSSL project chose the path they took. It smells heavily of "Not Invented Here" to me.

Surely some future OpenSSL version will fix this mess?

*) lists.haxx.se/pipermail/daniel

lists.haxx.se[Daniel's week] January 10, 2025

Whoa, I just got a basic Python wrapper around ngtcp2 [server only] functional. Lots of error handling and edge cases need to be implemented.

The test that is working is a client (aioquic) connects, opens a stream, both sides send some data, and confirms that the other side received the data.

I really didn't think my last set of changes would make things work, I expected to hit some unimplemented parts.

TODO:
```
$ grep NotImplementedError ngtcp2.py | wc -l
15
```

Обновился #OpenSSL до 3.4.0 и опять без полноценной нормальной поддержки #QUIC, т.е. непригодный для #HTTP/3 на серверной стороне. И, соответственно, ещё не ясно на сколько хорошо сделана клиентская часть :)
Аж вспомнились времена, когда желая получить #curl поддерживающий нормально работу #HTTP/3 приходилось собирать его из исходников с #GnuTLS, вместо #OpenSSL.

#HTTP/3 работает не через #tcp/ip, а использует в качестве транспорта протокол #QUIC (Quick UDP Internet Connections), т.е. передаёт данные поверх #udp, без использования #tcp/ip, не устанавливая tcp-соединений. Вот картинка про современный #HTTP

Сам по себе #QUIC не умеет передавать данные в открытом виде, а может только через #TLS v1.3, т.е. в обязательном порядке только зашифрованные (используется вариант #TLS близкий к #DTLS, а не тот вариант #TLS что применяется повсеместно для tcp-соединений).

#curl может использовать разные альтернативы #OpenSSL, т.к. изначально спроектирован таким образом, что не привязан именно к #OpenSSL, вот официальная документация что и как с криптографическими бэкендами. Примерно там же есть сравнение разных бэкендов.

Что предлагаю по реализации HTTP/3 сами авторы?
Вот зелёным выделена комбинация библиотек, которую полагают наиболее стабильным и полноценным вариантом
Вся загвоздка в том, что #OpenSSL пытается содержать в себе реализацию #QUIC, а не использует реализацию в виде какой-то библиотеки.

Что получается с предлагаемой комбинацией?
Протокол #HTTP/3 реализуется через библиотеку #nghttp3, необходимая реализация #QUIC через #ngtcp2, а для TLS используется #GnuTLS или же #wolfSSL
Вот официальная документация с деталями по сборке отдельных составляющих. Если доступный в системе #GnuTLS далёк от свежих версий, то легко собирается из исходников.

В целом, про варианты #curl с поддержкой #HTTP/3 очень хорошо и достойно расписано здесь. Есть и перевод этой публикации на русском языке.

#https #http #openssl #lang_ru @Russia
Continued thread

And in attempting to add libssl to be wrapped, I have now hit that ABI issue.

Simply loading libssl via CDLL causes other tests to break, because the new libssl overrides the symbols causing an ABI compatibility problem.

I hadn't hit that problem yet, because I never got far enough to calling an ngtcp2 function that tried to access the SSL ABI.

Now I have to decide how to handle this.

#QUIC#ngtcp2#ctypes
Replied in thread

@nlnetlabs @fedora First discovery is that we do not have even #ngtcp2 library in Fedora yet. That man openssl-quic can already provide client connection API, but server API is not yet available via #OpenSSL releases. There is openssl+quic fork, which is unlikely to ever be in Fedora. We could end with unbound linked to openssl, but libngtcp2 linked to gnutls. Definitely not as straight forward as I have expected.