lyskomd-qa August 2014

lyskomd-qa@lists.lysator.liu.se

1 participants
5 discussions

[Bug 133] Cryptography needed
by bugzilla-daemon＠lysator.liu.se 08 Aug '14

08 Aug '14

https://bugzilla.lysator.liu.se/show_bug.cgi?id=133 Albin Sunnanbo <albin(a)sunnanbo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |albin(a)sunnanbo.com --- Comment #21 from Albin Sunnanbo <albin(a)sunnanbo.com> --- There is a race condition during TLS initialization if the server decides to send async during between the client has requested TLS initialization and the initialization actually starts. See discussion in LysLys ====================================================================== Author: Albin! (Hej, vad har du kompilerat idag?) Text No: 17466434 Creation time: 2009-04-14 19:25:35 Recipient: LysKOM utvecklingsmöte (för) #KOM (Utveckling och test) Recipient: LysKOM (-) Systemet, protokollet mm ---------------------------------------------------------------------- Subject: Kryptera LysKOM ---------------------------------------------------------------------- * Dokumentationen bör påpeka att det är bra att sätta accept-async till tomma listan innan man ger sig på start-tls, annars är chansen mycket god att man får en async (t.ex. att man själv loggat in) emellan när man tror att man skall få svar på sin TLS handshake... ====================================================================== Author: Anders E Larsson (andersrymdblogg.wordpress.com) Text No: 17466458 Creation time: 2009-04-14 19:32:19 Recipient: LysKOM utvecklingsmöte (för) #KOM (Utveckling och test) Recipient: LysKOM (-) Systemet, protokollet mm ---------------------------------------------------------------------- Subject: Kryptera LysKOM ---------------------------------------------------------------------- Vore det helt befängt att försöka få servern att hålla inne med asynkrona meddelanden tills TLS hoppat igång? Det känns som en gotcha man skulle kunna slippa. ====================================================================== Author: Albin! (Hej, vad har du kompilerat idag?) Text No: 17466493 Creation time: 2009-04-14 19:50:22 Recipient: LysKOM utvecklingsmöte (för) #KOM (Utveckling och test) Recipient: LysKOM (-) Systemet, protokollet mm ---------------------------------------------------------------------- Subject: Kryptera LysKOM ---------------------------------------------------------------------- Jag tänkte också det först... men det är bara det att servern inte vet om klienten tänker köra en start-tls förrän klienten verkligen gjort det, och då är det redan försent, för då kan det redan ligga ett antal asyncs ute på tråden... Man skulle ev. kunna låta tls-supported pausa alla asyncs, men det känns väldigt subtilt. En annan möjlighet är att i den nya server-versionen alltid börja med alla asyncs avlsagna, men då riskerar man att ha sönder en mängd gamla klienter. ====================================================================== Author: ceder (-) Per Cederqvist Text No: 17466865 Creation time: 2009-04-14 22:19:58 Recipient: LysKOM utvecklingsmöte (för) #KOM (Utveckling och test) Recipient: LysKOM (-) Systemet, protokollet mm ---------------------------------------------------------------------- Subject: Kryptera LysKOM ---------------------------------------------------------------------- Nu vet jag inte hur patchen gör, för jag har inte hunnit studera den, men jag tycker start-tls borde vara definierad så här: - Klienten skickar start-tls. - Servern svar skickas i klartext. - Om server svarar att start-tls gick fel (t ex för att stöd för TLS inte finns, eller nekas av administrativa skäl), så händer inget mer. Klienten får inte börja göra en TLS-handskakning. Klienten kan koppla ner förbindelsen om den är paranoid (och bör nog göra det per default, om den någonsin lyckats köra TLS mot just den servern). - Om servern svarar att start-tls lyckades, så måste klienten påbörja TLS-handskakningen. Servern garanterar att inget data skickas innan TLS-handskakningen avslutats. - Själva TLS-handskakningen kan misslyckas. Då skickas (så vitt jag förstår) alltid en alert som beskriver vad som hänt. När en sådan alert har skickats är förbindelsen åter i klartext (eller så ska protokoll A speca att förbindelsen ska kopplas ner). - Om TLS-handskakningen lyckas, så slutar den med att medelandet "Finished" skickas i vardera riktningen. Direkt när "Finished" skickats kan man börja sända krypterade meddelanden. Asynkrona meddelanden borde inte vara något problem. Servern borde automatiskt se till att inte skicka något efter svaret på start-tls, utan invänta klientens TLS-handskakning. (Och kommer det ingen TLS-handskakning inom någon timme eller så ska servern koppla ner!) ====================================================================== ... ====================================================================== Author: ceder (-) Per Cederqvist Text No: 17467612 Creation time: 2009-04-15 09:21:10 Recipient: LysKOM utvecklingsmöte (för) #KOM (Utveckling och test) Recipient: LysKOM (-) Systemet, protokollet mm ---------------------------------------------------------------------- Subject: Kryptera LysKOM ---------------------------------------------------------------------- Jag skulle som sagt föredra det här: C: 0 999 # Om "999" är START-TLS S: =0 C: ClientHello S: ServerHello Men om det blir enklare kan man ju i stället tänka sig att man gör så här: C: 0 999 S: =0 C: ClientHello S: <eventuella asynkrona meddelanden> S: <ett nytt asynkront meddelande: "tls-handskakningen börjar nu"> S: ServerHello Men att ha det så här tror jag fungerar dåligt: C: 0 999 S: =0 C: ClientHello S: <eventuella asynkrona meddelanden> S: ServerHello Nu har jag i och för sig inte tittat på hur ett ServerHello ser ut, byte för byte. Eftersom serverns svar alltid börjar med "=", "%" eller ":", så kanske man kan se skillnad på de och ServerHello? Fast det känns inte så stabilt. ====================================================================== Author: Albin! (Hej, vad har du kompilerat idag?) Text No: 17469342 Creation time: 2009-04-15 20:42:41 Recipient: LysKOM utvecklingsmöte (för) #KOM (Utveckling och test) Recipient: LysKOM (-) Systemet, protokollet mm ---------------------------------------------------------------------- Subject: Kryptera LysKOM ---------------------------------------------------------------------- Jag skulle föredra den första varianten. ====================================================================== Author: Albin! (Hej, vad har du kompilerat idag?) Text No: 17469370 Creation time: 2009-04-15 20:57:41 Recipient: LysKOM utvecklingsmöte (för) #KOM (Utveckling och test) Recipient: LysKOM (-) Systemet, protokollet mm ---------------------------------------------------------------------- Subject: Kryptera LysKOM ---------------------------------------------------------------------- Variant två blir inte så bra att implementera i .NET i alla fall, när jag börjar min handshake så tar den över inkommande dataström direkt och den måste alltså vara "framme" innan jag startar mitt ClientHello. C: 0 999 S: =0 S: <eventuella asynkrona meddelanden> S: <ett nytt asynkront meddelande: "tls-handskakningen börjar nu"> C: ClientHello S: ServerHello Skulle också kunna funka. Men det känns inte helt stabilt med ett protokoll som säger "någon gång i framtiden så kommer vi börja". ====================================================================== -- You are receiving this mail because: You are the QA Contact for the bug.

1 0

[Bug 133] Cryptography needed
by bugzilla-daemon＠lysator.liu.se 08 Aug '14

08 Aug '14

1 0

[Bug 133] Cryptography needed
by bugzilla-daemon＠lysator.liu.se 08 Aug '14

08 Aug '14

1 0

[Bug 133] Cryptography needed
by bugzilla-daemon＠lysator.liu.se 08 Aug '14

08 Aug '14

1 0

[Bug 1702] New: IPv6: DNS requests block the server
by bugzilla-daemon＠lysator.liu.se 05 Aug '14

05 Aug '14

https://bugzilla.lysator.liu.se/show_bug.cgi?id=1702 Bug ID: 1702 Summary: IPv6: DNS requests block the server Classification: LysKOM Product: lyskomd Version: master (unreleased) Hardware: All OS: All Status: NEW Severity: major Priority: P5 Component: server Assignee: ceder(a)lysator.liu.se Reporter: ceder(a)lysator.liu.se QA Contact: lyskomd-qa(a)lists.lysator.liu.se When a client connects, the server tries to resolve the IP address of the client. In the beginning, this was done in a blocking way. Bug 627 added non-blocking lookup of IPv4 addresses, but IPv6 adresses are still looked up in a blocking way. We need to add IPv6 support to adns and possibly the liboop adapter. (If we are lucky, newer versions of adns have the necessary support. Check that.) There is code in src/libraries/libisc-new/src/isc_socket.c that checks for this condition: /* adns does not yet support IPv6 addresses, so if this is an IPv6 socket we have to use the old blocking method of host name lookup. */ -- You are receiving this mail because: You are the QA Contact for the bug.

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

lyskomd-qa August 2014