Unterstützung für TLS v1.1/TLS v1.2 in RCurl

Question

ETA: Per https://github.com/hiratake55/RForcecom/issues/42 , it looks like the author of the rforcecom package has updated rforcecom to use httr instead of RCurl (as of today, to be uploaded to CRAN tomorrow, 7/1/16), so my particular issue will be solved at that point. However, the general case (implementing TLS 1.1/1.2 in RCurl) may still be worth pursuing for other packages. Or everyone may just switch to the more recent curl package instead of RCurl.

Hintergrund: Ich verwende das rforcecom-Paket, um mehrere Monate mit Salesforce zu kommunizieren. Salesforce hat kürzlich die Unterstützung für TLS v1.0 deaktiviert und TLS v1.1 oder höher in seinen Sandboxen erfordert. Dieses Update wird für Produktionsumgebungen im März 2017 durchgeführt.

rforcecom verwendet RCurl für die Kommunikation mit salesforce.com-Servern. Im Allgemeinen wird das curlPerform Verfahren verwendet wird, das so etwas wie dies umgesetzt wird (in diesem Beispiel ist aus rforcecom.login.R):

h <- basicHeaderGatherer() 
t <- basicTextGatherer() 
URL <- paste(loginURL, rforcecom.api.getSoapEndpoint(apiVersion), sep="") 
httpHeader <- c("SOAPAction"="login","Content-Type"="text/xml") 
curlPerform(url=URL, httpheader=httpHeader, postfields=soapBody, headerfunction = h$update, writefunction = t$update, ssl.verifypeer=F) 

dies für eine Weile für mich gearbeitet hat, wie ich bereits erwähnt. Nun, da Salesforce hat TLS v1.0 auf Sandbox deaktiviert, aber nicht mit dem folgenden Fehler:

UNSUPPORTED_CLIENT: TLS 1.0 has been disabled in this organization. Please use TLS 1.1 or higher when connecting to Salesforce using https. 

ich geändert habe und sourced (ohne es in der lokalen Kopie des Pakets Umsetzung, wie ich bin nicht erfahren genug, um dies zu tun) eine Änderung an meiner lokalen Kopie des Login-Moduls für RForcecom, und ich habe durch Experimente festgestellt, dass ich eine der vorhandenen aufgezählten Werte für SSLVERSION erfolgreich hinzufügen kann, indem Sie sslversion=SSLVERSION_TLSv1, sslversion=SSLVERSION_SSLv3, etc. hinzufügen curlPerform Optionen, wo es heißt. All dies gibt mir jedoch den gleichen Fehler wie oben. Wenn ich versuche, eine der Optionen zu verwenden, die in libcurl implementiert ist, aber nicht in RCurl (SSLVERSION_TLSv1.1, SSLVERSION_TLSv1.2), habe ich die folgende Fehlermeldung erhalten:

Error in merge(list(...), .opts) : object 'SSLVERSION_TLSv1.1' not found 

oder:

Error in merge(list(...), .opts) : object 'SSLVERSION_TLSv1.2' not found 

Ich habe überprüft, mit curlVersion(), dass meine libcurl-Version ist 7.40.0, die nach https://curl.haxx.se/libcurl/c/CURLOPT_SSLVERSION.html unterstützt diese Optionen. Ich kann RCurl jedoch nicht dazu bringen, sie zu erkennen.

An diesem Punkt, was ich suche, ist eine Möglichkeit, RCurl TLS v1.1 oder TLS v1.2 zu verwenden, und ich würde sehr schätzen jegliche Unterstützung, die ich damit bekommen kann. Ich entschuldige mich für irgendwelche Probleme/Probleme mit meiner Frage, da dies das erste Mal ist, dass ich mich selbst erkundige. Ich war bisher immer in der Lage, mich durchzulesen, indem ich die Fragen und Antworten anderer Leute lese.

Answer 1

RCurl ist eine Schnittstelle zu libcurl und was es unterstützt, hängt von letzterem ab. Es ist möglich, dass Ihre libcurl mit einer älteren Version von OpenSSL erstellt wurde, die keine Unterstützung für TLS v1.1 oder v.1.2 bietet. Sie können Ihren SSL-Version von R wie folgt ermitteln:

RCurl::curlVersion()$ssl_version 

Ich denke, dass standardmäßig (z ssl Option CURL_SSLVERSION_DEFAULT), während des SSL-Handshake, der Server und der Client würde auf die neueste Version zustimmen, dass sie beide unterstützen. Um dies zu ermöglichen, müssten Sie OpenSSL auf eine neuere Version updaten, libcurl damit neu kompilieren und RCurl so neu erstellen, dass es die Updates registriert.

Das heißt, Sie können eine bestimmte SSL-Version erzwingen, die nicht in RCurl definiert ist, indem Sie den Integer-Wert der erforderlichen Option selbst übergeben.Die Zahlen Sie suchen, kann aus den in the curl header file on GitHub definiert C enum ableiten:

enum { 
    CURL_SSLVERSION_DEFAULT, // 0 
    CURL_SSLVERSION_TLSv1, /* TLS 1.x */ // 1 
    CURL_SSLVERSION_SSLv2, // 2 
    CURL_SSLVERSION_SSLv3, // 3 
    CURL_SSLVERSION_TLSv1_0, // 4 
    CURL_SSLVERSION_TLSv1_1, // 5 
    CURL_SSLVERSION_TLSv1_2, // 6 
    CURL_SSLVERSION_TLSv1_3, // 7 

    CURL_SSLVERSION_LAST /* never use, keep last */ // 8 
}; 

Zum Beispiel:

# the data of you post request 
nameValueList = list(data1 = "data1", data2 = "data2") 

CURL_SSLVERSION_TLSv1_1 <- 5L 
CURL_SSLVERSION_TLSv1_2 <- 6L 

# TLS 1.1 
opts <- RCurl::curlOptions(verbose = TRUE, 
          sslversion = CURL_SSLVERSION_TLSv1_1, ...) 

# TLS 1.2 
opts <- RCurl::curlOptions(verbose = TRUE, 
          sslversion = CURL_SSLVERSION_TLSv1_2, ...) 

# finally, POST the data 
RCurl::postForm(URL, .params = nameValueList, .opts = opts) 

In der Regel ist dies keine gute Praxis sein kann, weil die Autoren von cURL entscheiden könnten, Um die Werte zu ändern (obwohl ich glaube, dass die Chancen gering sind), haben diese Optionen.