<p>I'm attempting to explicitly execute a TLS Handshake (i.e. StartTLS) and when doing so receive a version mismatch error.</p>
<p>what would cause tls.Handshake() to error with
<code>
received record with version 502 when expecting version 303
</code></p>
<p>I'm not sure where to find or how to control the versions in this context. I see the logic checking the versions in conn.go</p>
<pre><code>if c.haveVers && vers != c.vers {
588 c.sendAlert(alertProtocolVersion)
589 msg := fmt.Sprintf("received record with version %x when expecting version %x", vers, c.vers)
590 return c.in.setErrorLocked(c.newRecordHeaderError(msg))
591 }
</code></pre>
<p>but am uncertain how to find and or specify versions that would match and allow a successful handshake.</p>
<hr/>**评论：**<br/><br/>alexwhoizzle: <pre><p>Looking at RFC4642 (<a href="https://tools.ietf.org/html/rfc4642" rel="nofollow">https://tools.ietf.org/html/rfc4642</a>) it says:</p>
<blockquote>
<p>2.2. STARTTLS Command</p>
<p>2.2.1. Usage</p>
<p>This command MUST NOT be pipelined.</p>
<p>Syntax
STARTTLS</p>
<p>Responses</p>
<pre><code> 382 Continue with TLS negotiation
502 Command unavailable [1]
580 Can not initiate TLS negotiation
</code></pre>
<p>[1] If a TLS layer is already active, or if authentication has
occurred, STARTTLS is not a valid command (see Section 2.2.2).</p>
</blockquote>
<p>...</p>
<blockquote>
<p>A server MUST NOT return the STARTTLS
capability label in response to a CAPABILITIES command received after
a TLS handshake has completed, and a server MUST respond with a 502
response code if a STARTTLS command is received while a TLS session
is already active.</p>
</blockquote>
<p>It seems like you are trying to handshake on TLS connection that has already been established. Make sure that you check the server's capabilities response before you call STARTTLS. </p></pre>Rabarar: <pre><p>Thanks! I think that's it - an implicit read call invoked a handshake and it's already occurred.</p>
<p>Thanks again for the insights!!</p></pre>
