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.
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.
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.
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.
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.