Qt-contributors-summit-2013-Qt Network CS 2013: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
m (Categorize) |
||
(4 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
{{Cleanup | reason=Auto-imported from ExpressionEngine.}} | |||
[[Category:QtCS2013]] | |||
[[Category:Developing Qt::Network]] | |||
=Qt Network Session – Qt Contributors Summit 2013= | |||
==Talking Points== | |||
* Option to add random padding to https requests. This makes us more resistant to the various https attacks that have been floating around. * X-Qt-Padding: some noise of varying length *Recommendation 3 from http://www.isg.rhul.ac.uk/tls/RC4biases.pdf | |||
* Who is working on the stack? | |||
* What's up with the constant failing tests in the CI, and how can we fix the situation? | |||
* Support for diffie-hellman ciphers | |||
* Support for redirects | |||
* Pause on connect | |||
* Performance | |||
* Peter's chromium qnam port | |||
* Automatic fallback support | |||
* Certificate store <span class="caps">API</span> / Caching intermediates | |||
* <span class="caps">OCSP</span> support | |||
* Replacing the <span class="caps">QNAM</span> disk cache | |||
* <span class="caps">HTTP</span> 2.0 / <span class="caps">SPDY</span> support | |||
* Web sockets | |||
* Enginio and Qt network | |||
* Webkit2 and custom QNetworkAccessManagers | |||
Off topic, but related: | |||
* PBKDF2 / BCrypt support (QtCore really) | |||
* Should we warn if running as root? If running suid? | |||
Notes by Thiago: | |||
* DH key exchange | |||
** no public <span class="caps">API</span> | |||
** easy to implement, hard to test | |||
* <span class="caps">OCSP</span> | |||
** adds latency: needs to query the <span class="caps">OCSP</span> server | |||
** Richard implemented one year ago | |||
** still works, but hasn't worked on it in a while | |||
** enabled by default | |||
** QSslSocket level | |||
* Certificate store: | |||
** storing intermediate certs from broken servers that don't return the whole chain | |||
** browsers do that to work around issues in the wild | |||
** adds security | |||
** certificates are not trusted, so they don't add a new security attack vector | |||
** virtual QSslCertificate QAbstractSslCertificateStore::certificateForId(QSslCertificateId) | |||
* <span class="caps">QNAM</span> redirects | |||
** discussed in the DD Contributor Day | |||
** vector for insecurity (users do it wrong) | |||
** should be configurable | |||
** we don't need to fix this for the browser case → they already have the code | |||
** we need it only for the simple application cases | |||
** allow redirect from <span class="caps">HTTP</span> to <span class="caps">HTTPS</span>, allow within-protocol | |||
** could work with pausing | |||
** readyRead & metaDataChanged from the final, sslErrors per connection | |||
* Pause on connect: | |||
** Already discussed, implementation challenges and details known | |||
** Work is missing (Peter doesn't have time) | |||
* Performance: latency problems | |||
** Helped by the pre-connect | |||
* Replacing <span class="caps">QNAM</span> port: | |||
** With Blink: | |||
*** difficult, it's too big for QtNetwork | |||
*** no guarantee that we'll get a "library" interface | |||
** libcurl: | |||
*** they're behind us | |||
* <span class="caps">SPDY</span> / <span class="caps">HTTP</span>/2.0: | |||
** <span class="caps">HTTP</span>/2.0 adopted <span class="caps">SPDY</span> 3.0's transport format | |||
*** we can start supporting <span class="caps">SPDY</span> to get on our way to <span class="caps">HTTP</span>/2.0 | |||
** libcurl has started |
Latest revision as of 17:27, 6 January 2017
This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine. Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean. |
Qt Network Session – Qt Contributors Summit 2013
Talking Points
- Option to add random padding to https requests. This makes us more resistant to the various https attacks that have been floating around. * X-Qt-Padding: some noise of varying length *Recommendation 3 from http://www.isg.rhul.ac.uk/tls/RC4biases.pdf
- Who is working on the stack?
- What's up with the constant failing tests in the CI, and how can we fix the situation?
- Support for diffie-hellman ciphers
- Support for redirects
- Pause on connect
- Performance
- Peter's chromium qnam port
- Automatic fallback support
- Certificate store API / Caching intermediates
- OCSP support
- Replacing the QNAM disk cache
- HTTP 2.0 / SPDY support
- Web sockets
- Enginio and Qt network
- Webkit2 and custom QNetworkAccessManagers
Off topic, but related:
- PBKDF2 / BCrypt support (QtCore really)
- Should we warn if running as root? If running suid?
Notes by Thiago:
- DH key exchange
- no public API
- easy to implement, hard to test
- OCSP
- adds latency: needs to query the OCSP server
- Richard implemented one year ago
- still works, but hasn't worked on it in a while
- enabled by default
- QSslSocket level
- Certificate store:
- storing intermediate certs from broken servers that don't return the whole chain
- browsers do that to work around issues in the wild
- adds security
- certificates are not trusted, so they don't add a new security attack vector
- virtual QSslCertificate QAbstractSslCertificateStore::certificateForId(QSslCertificateId)
- QNAM redirects
- discussed in the DD Contributor Day
- vector for insecurity (users do it wrong)
- should be configurable
- we don't need to fix this for the browser case → they already have the code
- we need it only for the simple application cases
- allow redirect from HTTP to HTTPS, allow within-protocol
- could work with pausing
- readyRead & metaDataChanged from the final, sslErrors per connection
- Pause on connect:
- Already discussed, implementation challenges and details known
- Work is missing (Peter doesn't have time)
- Performance: latency problems
- Helped by the pre-connect
- Replacing QNAM port:
- With Blink:
- difficult, it's too big for QtNetwork
- no guarantee that we'll get a "library" interface
- libcurl:
- they're behind us
- With Blink:
- SPDY / HTTP/2.0:
- HTTP/2.0 adopted SPDY 3.0's transport format
- we can start supporting SPDY to get on our way to HTTP/2.0
- libcurl has started
- HTTP/2.0 adopted SPDY 3.0's transport format