Hi,
Thanks for the ideas, but we just use a self signed certificate. I am not really an expert with certificates, would there be any kind of lookup done to a certificate authority or other internet site with a self signed certificate ?
If so is there any way to disable it ? we are just using svn internaly in an small company and dont have a big IT department.
regards
Matthew J Fletcher
> -----Original Message-----
> From: Brian Brophy [mailto:brianmbrophy_at_gmail.com]
> Sent: 22 April 2011 16:39
> To: Matthew Fletcher; users_at_subversion.apache.org
> Subject: Re: Slow initial repo access (https method)
>
> Is your trace below only showing traffic from client to SVN
> server? If so, try grabbing all traffic from the client to
> see what else may be going on. There are a couple features
> of SSL which may explain this.
>
> First, does your certificate signing chain include
> intermediary signers? An example would be something like
> VeriSign Public Primary G3
> -> VeriSign International Root G5 -> Your Certificate. If so, the
> server should have all signers in the chain available to it,
> so that if the client needs them to verify the handshake, the
> server can hand them down. If the client determines it needs
> the intermediaries and the server does not have them, the
> client may go out to the provider (ie,
> VeriSign) and attempt to download the missing certificates in
> order to perform the verification.
>
> Second, some SSL certificates include a configuration for a
> revocation link. This is a location (typically a publicly
> accessible URL) that the client can view on the certificate's
> metadata, and if implemented, call out to the revocation
> location in order to determine if the certificate the client
> is attempting to handshake with (ie, your server cert) has
> since been revoked by the signer. It is a mechanism for the
> signer to "de-certify" a certificate that otherwise would be
> ok (ie, start/end dates are within window, cn matches hostname, etc).
>
> Some thoughts,
> Brian
>
> Matthew Fletcher wrote:
> > Hi,
> >
> > We are using svn 1.6.16 on the server and have noticed that
> there is a large pause in the inital https requests, (snip of
> wireshark shown bellow). Basically it looks like this is a
> server side issue but i am not sure where to look for logs (apache ?).
> >
> > 10.141.80.130 (server)
> > 10.141.81.134 (client)
> >
> > No. Time Source Destination
> Protocol Info
> > 1 0.000000 10.141.81.134 10.141.80.130
> TCP 50186 > pcsync-https [SYN] Seq=0 Win=8192 Len=0
> MSS=1460 SACK_PERM=1
> > No. Time Source Destination
> Protocol Info
> > 2 0.000125 10.141.80.130 10.141.81.134
> TCP pcsync-https > 50186 [SYN, ACK] Seq=0 Ack=1
> Win=16384 Len=0 MSS=1460 SACK_PERM=1
> > No. Time Source Destination
> Protocol Info
> > 3 0.000166 10.141.81.134 10.141.80.130
> TCP 50186 > pcsync-https [ACK] Seq=1 Ack=1 Win=64240 Len=0
> > No. Time Source Destination
> Protocol Info
> > 4 0.000307 10.141.81.134 10.141.80.130
> TCP 50186 > pcsync-https [PSH, ACK] Seq=1 Ack=1
> Win=64240 Len=227
> > No. Time Source Destination
> Protocol Info
> > 5 0.013041 10.141.80.130 10.141.81.134
> TCP pcsync-https > 50186 [ACK] Seq=1 Ack=228
> Win=65308 Len=1460
> > No. Time Source Destination
> Protocol Info
> > 6 0.013068 10.141.80.130 10.141.81.134
> TCP pcsync-https > 50186 [PSH, ACK] Seq=1461 Ack=228
> Win=65308 Len=13
> > No. Time Source Destination
> Protocol Info
> > 7 0.013084 10.141.81.134 10.141.80.130
> TCP 50186 > pcsync-https [ACK] Seq=228 Ack=1474
> Win=64240 Len=0
> > No. Time Source Destination
> Protocol Info
> > 8 0.029234 10.141.81.134 10.141.80.130
> TCP 50186 > pcsync-https [PSH, ACK] Seq=228 Ack=1474
> Win=64240 Len=198
> > No. Time Source Destination
> Protocol Info
> > 9 0.033499 10.141.80.130 10.141.81.134
> TCP pcsync-https > 50186 [PSH, ACK] Seq=1474 Ack=426
> Win=65110 Len=266
> > No. Time Source Destination
> Protocol Info
> > 10 0.225080 10.141.81.134 10.141.80.130
> TCP 50186 > pcsync-https [ACK] Seq=426 Ack=1740
> Win=63974 Len=0
> > No. Time Source Destination
> Protocol Info
> > 11 15.123199 10.141.81.134 10.141.80.130
> TCP 50186 > pcsync-https [PSH, ACK] Seq=426 Ack=1740
> Win=63974 Len=485
> > No. Time Source Destination
> Protocol Info
> > 12 15.123238 10.141.81.134 10.141.80.130
> TCP 50186 > pcsync-https [PSH, ACK] Seq=911 Ack=1740
> Win=63974 Len=133
> > No. Time Source Destination
> Protocol Info
> > 13 15.123401 10.141.80.130 10.141.81.134
> TCP pcsync-https > 50186 [ACK] Seq=1740 Ack=1044
> Win=64492 Len=0
> > No. Time Source Destination
> Protocol Info
> > 14 15.124022 10.141.80.130 10.141.81.134
> TCP pcsync-https > 50186 [PSH, ACK] Seq=1740
> Ack=1044 Win=64492 Len=746
> >
> >
> > Note the giant 15 second wait between packets 10-11, and
> then fast afterwards.
> >
> > See the slow packets 10-11 in full bellow;
> >
> >
> > Frame 10: 54 bytes on wire (432 bits), 54 bytes captured (432 bits)
> > Ethernet II, Src: Dell_4e:1a:ce (00:1e:c9:4e:1a:ce), Dst:
> > Dell_cf:17:71 (00:1e:c9:cf:17:71) Internet Protocol, Src:
> 10.141.81.134 (10.141.81.134), Dst: 10.141.80.130 (10.141.80.130)
> > Version: 4
> > Header length: 20 bytes
> > Differentiated Services Field: 0x00 (DSCP 0x00:
> Default; ECN: 0x00)
> > Total Length: 40
> > Identification: 0x453c (17724)
> > Flags: 0x02 (Don't Fragment)
> > Fragment offset: 0
> > Time to live: 128
> > Protocol: TCP (6)
> > Header checksum: 0x0000 [incorrect, should be 0xfe71]
> > Source: 10.141.81.134 (10.141.81.134)
> > Destination: 10.141.80.130 (10.141.80.130) Transmission Control
> > Protocol, Src Port: 50186 (50186), Dst Port: pcsync-https
> (8443), Seq: 426, Ack: 1740, Len: 0
> > Source port: 50186 (50186)
> > Destination port: pcsync-https (8443)
> > [Stream index: 0]
> > Sequence number: 426 (relative sequence number)
> > Acknowledgement number: 1740 (relative ack number)
> > Header length: 20 bytes
> > Flags: 0x10 (ACK)
> > Window size: 63974
> > Checksum: 0xb73c [validation disabled]
> > [SEQ/ACK analysis]
> >
> >
> > Frame 11: 539 bytes on wire (4312 bits), 539 bytes captured (4312
> > bits) Ethernet II, Src: Dell_4e:1a:ce (00:1e:c9:4e:1a:ce), Dst:
> > Dell_cf:17:71 (00:1e:c9:cf:17:71) Internet Protocol, Src:
> 10.141.81.134 (10.141.81.134), Dst: 10.141.80.130 (10.141.80.130)
> > Version: 4
> > Header length: 20 bytes
> > Differentiated Services Field: 0x00 (DSCP 0x00:
> Default; ECN: 0x00)
> > Total Length: 525
> > Identification: 0x4546 (17734)
> > Flags: 0x02 (Don't Fragment)
> > Fragment offset: 0
> > Time to live: 128
> > Protocol: TCP (6)
> > Header checksum: 0x0000 [incorrect, should be 0xfc82]
> > Source: 10.141.81.134 (10.141.81.134)
> > Destination: 10.141.80.130 (10.141.80.130) Transmission Control
> > Protocol, Src Port: 50186 (50186), Dst Port: pcsync-https
> (8443), Seq: 426, Ack: 1740, Len: 485
> > Source port: 50186 (50186)
> > Destination port: pcsync-https (8443)
> > [Stream index: 0]
> > Sequence number: 426 (relative sequence number)
> > [Next sequence number: 911 (relative sequence number)]
> > Acknowledgement number: 1740 (relative ack number)
> > Header length: 20 bytes
> > Flags: 0x18 (PSH, ACK)
> > Window size: 63974
> > Checksum: 0xb921 [validation disabled]
> > [SEQ/ACK analysis]
> > Data (485 bytes)
> >
> > 0000 17 03 01 01 e0 5b aa 54 59 c4 53 f1 31 5a c3 00
> .....[.TY.S.1Z..
> > 0010 9f b8 89 74 7e 6a ce 5a a0 34 02 dc 78 6b a3 2d
> ...t~j.Z.4..xk.-
> > 0020 64 2f 60 dc c6 80 00 3f 01 20 50 02 d2 4d 70 f2
> d/`....?. P..Mp.
> > 0030 4f 9d 82 a6 3a cc 8f 18 3f a3 d7 0b ea 1d 33 1b
> O...:...?.....3.
> > 0040 84 b3 15 c2 5d de d5 6b 49 1a 72 a3 10 a2 8e b0
> ....]..kI.r.....
> > 0050 9c 82 9a 65 f0 05 38 3b 7d d2 9b 5c 1b ed b6 85
> ...e..8;}..\....
> > 0060 d5 0d 17 9a 99 5c a4 18 ac 12 d5 7d 26 82 a3 b3
> .....\.....}&...
> > 0070 d9 a2 66 07 52 d3 7f ea 26 69 f1 a5 ee a8 b9 21
> ..f.R...&i.....!
> > 0080 b9 98 d2 a8 e6 05 30 2d a2 53 8b 0b 59 bd 6e ed
> ......0-.S..Y.n.
> > 0090 9a b6 4e 9e 7a 57 ad 16 bc 4e 6b f8 48 e3 d2 b3
> ..N.zW...Nk.H...
> > 00a0 8f 19 2d e6 0a 06 bf 7f 71 e0 74 a2 8e fa 92 59
> ..-.....q.t....Y
> > 00b0 7e 00 24 06 41 c6 f0 bc 74 f3 39 af 3c e3 34 20
> ~.$.A...t.9.<.4
> > 00c0 f4 35 9f 70 40 c6 95 2a 69 61 98 ff 58 52 5e 03
> .5.p@..*ia..XR^.
> > 00d0 50 c1 60 d5 27 53 48 60 c4 1b e7 a6 49 1d 98 f0
> P.`.'SH`....I...
> > 00e0 46 8c 25 b5 1f 7b 93 79 1b 52 02 e5 fd 9e 2c 6d
> F.%..{.y.R....,m
> > 00f0 8e ed 6f 6c f3 8e 72 1e 76 0f 7c c0 f9 61 00 1c
> ..ol..r.v.|..a..
> > 0100 95 21 f8 f5 e1 32 bd 83 47 65 d2 f4 21 7e b0 20
> .!...2..Ge..!~.
> > 0110 d6 45 48 30 a1 6b e8 e3 8e f0 58 ad f7 9e 5b ff
> .EH0.k....X...[.
> > 0120 86 63 fe d1 1b 0c bb af e1 85 e1 d8 13 f0 00 78
> .c.............x
> > 0130 3a f6 de d6 77 40 be e8 e1 ab 4c e3 7c 7c ec 3d
> :...w@....L.||.=
> > 0140 4c 56 e9 42 11 cb 42 13 81 75 66 70 01 63 c5 40
> LV.B..B..ufp.c.@
> > 0150 fa 2e 39 86 64 ac 7a da 38 0e aa 15 62 b1 4f 6f
> ..9.d.z.8...b.Oo
> > 0160 f2 71 b8 12 64 f4 91 f2 1c 57 ae 15 05 20 42 2b
> .q..d....W... B+
> > 0170 a3 6e 24 01 dc 8c fa b0 49 2f 5e 68 68 29 1d de
> .n$.....I/^hh)..
> > 0180 c6 dc 14 44 76 91 6b 4b ed 4f 65 77 43 a1 56 df
> ...Dv.kK.OewC.V.
> > 0190 4a 66 8d 00 e9 96 f7 3a 60 dd 5a 3e e7 4f a5 ae
> Jf.....:`.Z>.O..
> > 01a0 6e 82 49 81 ce 4d a8 1e 2d 0d c6 ae 3e 5b ee 83
> n.I..M..-...>[..
> > 01b0 b0 29 72 91 48 57 54 72 f3 a1 59 46 cf ff dd 0b
> .)r.HWTr..YF....
> > 01c0 95 ef 03 2b fe c0 4c 47 f1 cd e8 46 07 17 7c 1a
> ...+..LG...F..|.
> > 01d0 d8 d0 bc 68 b4 ca 07 ec 73 87 eb 34 93 e5 1f 42
> ...h....s..4...B
> > 01e0 fa ce 60 11 f6 ..`..
> >
> >
> > any ideas why this packet takes so long to be created, or
> what operation preceded it can caused the slowness ?
> >
> >
> > regards,
> >
> > Matthew J Fletcher
> >
> >
> >
> **********************************************************************
> > Serck Controls Ltd, Rowley Drive, Coventry, CV3 4FH, UK A company
> > registered in England Reg. No. 4353634
> > Tel: +44 (0) 24 7630 5050 Fax: +44 (0) 24 7630 2437
> > Web: www.serck-controls.com Admin: post_at_serck-controls.co.uk A
> > subsidiary of Schneider Electric.
> >
> **********************************************************************
> > This email and files transmitted with it are confidential
> and intended
> > solely for the use of the individual or entity to whom they are
> > addressed. If you have received this email in error please
> notify the
> > above. Any views or opinions presented are those of the
> author and do
> > not necessarily represent those of Serck Controls Ltd.
> >
> > This message has been scanned for malware by Mailcontrol.
> > www.Mailcontrol.com
> >
>
Received on 2011-04-22 17:51:06 CEST