Source Code von MS-DOS 2.0 veröffentlicht

25 März 2014

Yuppiee! Der erste Schritt ist gemacht. Nach über 30 Jahren wird der Source Code von MS-DOS 2.0 veröffentlicht. Bis wir den Source Code von Windows 8.1 und nachfolgend sehen werden, wird es sicherlich nicht mehr ganz so lange dauern. http://www.heise.de/newsticker/meldung/Quelltexte-von-MS-DOS-und-Word-for-Windows-veroeffentlicht-2154723.html

Hier zum Source von MS-DOS: http://www.computerhistory.org/atchm/microsoft-ms-dos-early-source-code/, falls nicht wieder die Guru Meditation wegen Überlastung kommt.

MS-DOS 2.0 das war das Betriebssystem, welches damals auf den ersten IBM-XT-PCs lief, dem Nachfolger des ersten als solches benannten Personal Computer, dem IBM PC. Da gab es auch schon Festplatten mit 10MB und so, ach und die flexiblen Scheiben, die 5 1/4 Zoll großen, ähm – ah ja – Floppy Disks! So ein PC war damals richtig schwer und heute tragen wir um 100 ja sogar 1000fach leistungsfähigere Geräte in der Hosentasche. Wer das alte Feeling nochmal erleben möchte, hier der Link zum MS-DOS 2.0 Emulator im Browser: http://jsmachines.net/configs/pc/machines/5160/cga/256kb/demo/

Warum es bei Windows 8.1 keine 30 Jahre bis zur Source Code Veröffentlichung dauern wird? Na weil das .Net Framework 4.5.1 bereits in seiner reinsten Form einsehbar ist: http://referencesource.microsoft.com/. Auch sind weite Teile von ASP.NET bereits unter Open Source verfügbar.

Schließlich wird Microsoft irgendwann gezwungen sein allen Source Code zu veröffentlichen, da keiner mehr den ganzen Müll warten will, den die da über die Jahre angehäuft haben. Denen gehen ja jetzt schon die ganzen Techniker aus, die sich mit dem ganzen Zeugs beschäftigen wollen bzw. die da überhaupt noch durchblicken. Man sieht dies ganz deutlich in vielen Microsoft moderierten Foren. Was da teilweise für Antworten von MS-Mitarbeitern kommen. Oder wie oft fehlt es an technischen Beschreibungen in der Knowledge Base oder Technet. Alles klare Anzeichen, dass die letzten Jahre viel in die falsche Richtung lief. Aber die Cloud soll es ja retten. Mal sehen, was nächste Woche auf der Build der neue Oberindianer von sich gibt.

xn--bcher-kva.de oder was hat das mit Bücher.de zu tun? Die Geschichte von Punycode bzw. IDN, also Internationale Domain Namen.

1 März 2014

Seit einigen Jahren ist es bereits möglich Domainnamen mit Umlauten wie äöü zu erhalten. Fast jeder hat sich seither damit aber zurückgehalten, weil viele Programme damit nicht umgehen können.

Aber in letzter Zeit scheinen es mehr Domains zu werden und wenn es nur darum geht, diese zusätzlich zu benutzen, um am Ende wieder auf die Hauptdomain weiterzuleiten. Wer zum heutigen Tag, als dieser Blogeintrag geschrieben wurde, www.bücher.de eingibt, der landet bei www.buecher.de. Soweit ist alles paletti.

Wer nun aber hin und wieder irgendwelche LOG-Dateien auswertet oder untersucht, bzw. mysteriöse Problemfälle zu ergründen versucht, der stolpert irgendwann über das Kürzel xn--.

Die Erklärung dafür ist recht simpel. Die komplette Internetinfrastruktur stammt aus der 8 bzw. noch 7-Bit Computersteinzeit. Als man die DNS-Infrastruktur aufbaute, gab es bekanntlich ja nur die USA und die kennen nun mal nur A-Z und die Zahlen von 0-9. Als man Ende der 80iger Jahre Unicode einführte, war es aber bereits zu spät alle DNS-Systeme umzustellen und keiner wusste, ob Unicode sich jemals durchsetzen würde, denn schließlich verschlang es Unmengen an Bytes.

Wenn man heute das Internet nochmal neu entwickeln könnte, würde man natürlich von Anbeginn Unicode verwenden. Aber dafür ist es zu spät. Also haben clevere Leute sich mit einem Kniff beholfen. Es entstand der sogenannte Punycode der im RFC3492 spezifiziert wurde, ein Algorithmus, welcher dafür sorgt dass zwischen ASCII und Unicode Zeichen umgesetzt werden können, ohne dass Informationen verloren gehen. Damit man weiß, dass es sich um einen Punycode behandelten Buchstaben handelt, wird einfach ein Marker davor gesetzt. Der Marker ist eben dieses Kürzel xn--. In RFC3490 als ACE prefix bezeichnet. Da dieses Kürzel sonst nicht verwendet wird und vorkam, konnte man immer eindeutig sagen, wann die ASCII-Zeichen in Unicode gewandelt werden müssen. RFC3490 betitelt mit “Internationalizing of Domain Names for Applications” führte zu der Abkürzung IDNA. Da das RFC 2003 veröffentlicht wurde, sprach man später von IDNA2003. Im Jahr 2008 entdeckte man auf einmal, dass es auch Sprachen gibt, welche von rechts nach links geschrieben werden und es gab noch andere Ungereimtheiten. Diese wurden in RFC5890 behandelt, welches dann als IDNA2008 bezeichnet wurde.

So also zurück wieder zu www.bücher.de. Wer nun wissen möchte, wie bücher.de konvertiert aussieht, der kann ganz einfach Onlinedienste dafür verwenden, z. B. http://www.charset.org/punycode.php?encoded=xn--bcher-kva.de&decode=Punycode+to+normal+text. Bei

Bücher.de

kommt also

xn--bcher-kva.de

bei raus. Interessant ist auch die Variante mit Subdomain http://www.charset.org/punycode.php?decoded=www.b%C3%BCcher.de&encode=Normal+text+to+Punycode#results:

www.bücher.de

wird zu

http://www.xn--bcher-kva.de

Es wird also einfach das www. davor beibehalten.

Zu welchen Verwicklungen diese Dinge führen können, werden wir in nächster Zeit im einen oder anderen Blogbeitrag wieder finden.

Niemals eine virtuelle Maschine bei Microsoft Hyper-V im Rootverzeichnis hinterlegen

10 Februar 2014

Nun gibt es einen offiziellen KB-Artikel zum Thema VMs und Rootverzeichnis. Dies ist egal mit welcher Version von Hyper-V ein No-Go!

http://support.microsoft.com/kb/2928127/en-us?sd=rss&spid=16796

Netsh und 32-Bit 64-Bit Abhängigkeit

8 Februar 2014

In der vor Powershell 4.0 Zeit aber teilweise aktuell immer noch, benötigt man unter Windows hin und wieder Netsh. Mittels Netsh kann alles mögliche in Sachen Netzwerk konfiguriert werden, von Netzwerkadressen über Firewall bis hin zum Tracing von Ereignissen.

Hier einige Beispiele, wo auf diesem Blog bisher Netsh zum Einsatz kam: http://newyear2006.wordpress.com/?s=netsh

Wichtig zu wissen in diesem Zusammenhang ist, dass Netsh abhängig von der Umgebung reagiert, was einem oft nicht bewusst ist, denn es gibt einmal Netsh für 32-Bit und einmal für 64-Bit Umgebungen.

Im Fall von WinHttp Proxy Einstellungen ist dies wichtig zu wissen, denn sonst wirken sich gemachte Proxy Einstellungen nicht aus! http://blogs.msdn.com/b/jpsanders/archive/2010/09/16/winhttp-proxy-settings-in-64-bit-x64-environments.aspx

Erst seit Windows 8 bzw. Server 2012 wird bei den Proxy-Einstellungen dafür gesorgt, dass Netsh sich auf beide Bereiche auswirkt. (Siehe Kommentare).

Gefährliche NAS-Backups mit Windows 7, Windows 8, Windows 8.1 sowie Server 2008 R2, Server 2012 und Server 2012 R2 und Fehlercode 0xC03A0005 mit Meldung “Die Version unterstützt diese Version des Dateiformats nicht”

28 Januar 2014

Gerade aufgeschreckt durch den Fehler bei einem Kunden auf einem QNAP-NAS während eines Systembackups:

Fehler bei der um ‎2014‎-‎01‎-‎27T21:17:26.330867400Z gestarteten Sicherung. Fehlercode: "0xC03A0005" (Die Version unterstützt diese Version des Dateiformats nicht.). Suchen Sie in den Ereignisdetails nach einer Lösung, und führen Sie die Sicherung erneut aus, nachdem das Problem behoben wurde.

Das Problem wurde bereits im Zusammenhang mit Windows Server 2008 R2 und Windows 7 im November 2010 beschrieben: http://blogs.technet.com/b/asiasupp/archive/2010/11/03/windows-server-backup-failed-with-error-quot-the-version-does-not-support-this-version-of-the-file-format-quot.aspx. Kurz: Das NAS versucht das Backup über ein Sparsefile anzulegen, während das Windowsprogramm Blocklevelzugriff braucht, da es eine VHD-Datei anlegt und bestimmte Dinge berechnet und direkt in der Datei anspringt. Da Windows keine Kenntnis vom Verhalten mit dem Sparsefile hat, kommt es zu falschen Berechnungen und damit scheitert die Sache früher oder später. Deshalb berichten viele von Problemen zu unterschiedlichen Gelegenheiten.

Als Lösung wurde genannt, man möchte in der smb.conf “strict allocate = yes” eintragen und den Samba-Server neu starten. Dadurch wird der für die Backupdateien benötigte Speicher immer komplett belegt.

Mal abgesehen, dass dieser Vorgang den Einsatz von Telnet erfordert, funktioniert diese Lösung aber auch nicht. Wie hier im Forum von QNAP diskutiert wird: http://forum.qnap.com/viewtopic.php?f=24&t=87109. Teilweise wird die Einstellung ignoriert oder geht nach einem weiteren Systemstart verloren oder sorgt für unnötige Auslastung des NAS. Offenbar ist es auch nicht nur ein Problem von QNAP sondern alle NAS-Hersteller kennen dieses Problem. Also Netgears ReadyNAS, FreeNAS, Synology usw. scheinen alle das Problem zu haben.

Was ist nun die Alternative? iSCSI

iSCSI ist etwas schwieriger einzurichten aber scheinbar momentan die einzig sinnvolle Lösung, solange das betreffende NAS iSCSI-Unterstützung mitbringt. Aber auch iSCSI birgt seine Gefahren: http://newyear2006.wordpress.com/2013/01/05/windows-server-2008-r2-bzw-sbs-2011-datensicherung-fehlercode-2155348061/

Sollte all das der Grund sein, warum MS nun die Sicherung in die CloudOS propagiert?

Mausscrollrad funktioniert unter Ubuntu in Hyper-V VM nicht

25 Januar 2014

Microsoft bemüht sich ja wirklich, das Linux unterm Hyper-V zum Zug kommt. Wie immer aber, sind es die Kleinigkeiten, welche tierisch nerven und einen vom produktiven Arbeiten abhalten. So zum Beispiel, dass unter Ubuntu, wahrscheinlich unter Debian generell, das Mausscrollrad nicht funktioniert. Das Problem ist auch schon zu MS gedrungen, doch anstatt das Problem anzugehen und das Problem zu debuggen, fragt der Hauptentwickler der Linux Integration Features die Community nach einer Version, wo es funktionierte und möchte sich die Arbeit erleichtern indem er bisect einsetzt.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1240731

Bei älteren Versionen, kann man die LIS wie in diesem Artikel beschrieben nachrüsten: http://baudlabs.com/how-to-install-hyper-v-integration-services-in-ubuntu-12-04-lts/

Mehr Infos zu den Linux Integration Services (LIS): http://blogs.technet.com/b/virtualization/archive/2014/01/02/linux-integration-services-3-5-announcement.aspx

Animierte GIF-Grafiken erstellen unter Windows und Mac OS X

20 Januar 2014

Um schnell jemand etwas verdeutlichen zu können, ist es oft hilfreich eine Animation oder ein Video zu erstellen. Wenn jemand die Abfolge sieht, ist es einfach leichter den Zusammenhang zu erkennen.

Nun gibt es jede Menge Tools für diese Zwecke, eines der kleinsten und einfachsten ist LICEcap: http://www-dev.cockos.com/licecap/. Es läuft unter Windows und Mac OS X, ist superklein und erlaubt sogar das Einblenden von Texten. Der Ausschnitt ist frei wählbar und sogar verschiebbar. Bei längeren Passagen kann man einfach die Aufnahme pausieren.

Am Ende erhält man eine animierte GIF-Datei, welche in jedem Desktop-Browser wie IE oder Chrome animiert dargestellt wird.

Auf virtuelle Maschinen eines Microsoft Hyper-V Server 2012 R2 mittels FreeRDP zugreifen

8 Januar 2014

Mit der aktuellen, umsonst verfügbaren Version des Microsoft Hyper-V Server 2012 R2 kann man mittels Powershell per Commandline mittlerweile fast jeden Bereich administrieren. Das einzig störende ist, wenn man Netzwerkkartenprobleme hat oder Schwierigkeiten hat einen Windows 8.1 Client für die Remoteadministration anzubinden. Powershell ist zwar mächtig, allerdings ist es manchmal hilfreich, wenn man direkt auf eine virtuelle Maschine zugreifen und diese direkt steuern kann.

Es gab zwar schon länger käufliche Lösungen, wie den 5Nine Manager, aber es gibt noch eine bessere Lösung: FreeRDP! Dank der Offenlegung des RPD-Protokolls seitens Microsoft, gibt es keine großen Geheimnisse mehr zur Implementierung. Hier das Projekt: http://www.freerdp.com/ und alles steht feinsäuberlich im Source auf Github. Es gibt sogar Unterstützung für Mac, Linux, Android sowie iOS. Was will man mehr.

Am einfachsten um FreeRDP unter Hyper-V nutzen zu können, verwendet man die 3MB-Variante von cloudbase.it http://www.cloudbase.it/using-freerdp-to-connect-to-the-hyper-v-console/, dort findet man unten diesen Downloadlink: http://www.cloudbase.it/downloads/FreeRDP_powershell.zip. Die Version ist explizit für die 2012 R2 Version freigegeben.

Von der FreeRDP-Geschichte abgesehen, gilt es auch die anderen Dinge von Cloudbase in Richtung OpenStack an sich zu beachten!

SSL/TLS Fehler in Powershell, bzw. wie man Zertifikatsprobleme unter Windows analysieren kann

4 Januar 2014

Beim Herumspielen mit Chocolatey, dazu ein anderes Mal mehr, gab es Probleme auf einem Windows XP-Rechner. Der Windows XP Rechner war für Chocolatey noch nicht vorbereitet, d. h. er hatte zwar .Net 1, 2 und 3.5 bereits aber noch kein .Net Framework 4. Powershell 2 war bereits installiert.

Ausgangslage
Der Aufruf von

@powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString(‘https://chocolatey.org/install.ps1′))" && SET PATH=%PATH%;%systemdrive%\chocolatey\bin

für die Installation, führte zu folgender Fehlermeldung:

Exception calling "DownloadString" with "1" argument(s): "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel."
At line:1 char:47
+ iex ((new-object net.webclient).DownloadString <<<< (‘https://chocolatey.org/
install.ps1′))
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : DotNetMethodException

Der entscheidende Punkt ist oben rot markiert. Aber was macht man jetzt? Die Meldung ist leider doch zu allgemein.

Erster Versuch mehr Infos zum Fehler zu bekommen
Powershell kennt das $error Objekt. In diesem ist immer der letzte Fehler enthalten. Aber gleichzeitig sind bestimmte Randbedingungen und tiefergehende Infos zum Fehler abrufbar. Wichtig: Wenn man beim Rumspielen einen neuen Fehler verursacht, dann gehts schnell durcheinander und man untersucht nicht den eigentlichen Fehler, sondern einen nachfolgenden! Also geht man zuerst her und sichert den Fehler:

$myE = $error[0]

Damit kann nun nichts schiefgehen und mittels verschiedenen Abfragen kommt man dann irgendwann dazu:

((($myE).Exception).InnerException).Innerexception
The remote certificate is invalid according to the validation procedure.

Aha, wir haben also ein Zertifikatsproblem.

Prüfung mittels Browser
Aber welches Zertifikat macht nun die Probleme? Wie kann man dies überprüfen? Ein einfacher Versuch ist mittels Browser, in diesem gibt man einfach im aktuellen Fall https://chocolatey.org ein und schaut was passiert. Wer jetzt Chrome benutzt, der ist fein raus und bleibt verdutzt zurück, wer es aber mit dem Internet Explorer probiert, welcher den gleichen Weg einschlägt wie eben Powershell, bekommt diese Meldung:

Es besteht ein Problem mit dem Sicherheitszertifikat der Website.

Das Sicherheitszertifikat dieser Website wurde für eine andere Adresse der Website ausgestellt.

Die Sicherheitszertifikatprobleme deuten eventuell auf den Versuch hin, Sie auszutricksen bzw. Daten die Sie an den Server gesendet haben abzufangen.

Es wird empfohlen, dass Sie die Webseite schließen und nicht zu dieser Website wechseln.

Klicken Sie hier, um diese Webseite zu schließen.

Laden dieser Website fortsetzen (nicht empfohlen).

Weitere Informationen

Ja das kennen wir schon. Wenn man aber “Laden dieser Website fortsetzen (nicht empfohlen)” anklickt, bekommt man den bekannten roten Balken des IE mit dem Zertifikatsfehler. Dort kann man nun auf Zertifikatsfehler klicken und sich die Sache etwas genauer anschauen. Blöd nur das, dass es nicht offensichtlich ist, wo das Problem wieder genau liegt. Auf jeden Fall bekommt man raus, dass es sich in diesem Fall um Geotrust-Zertfikate handelt. Übrigens bekommt man diese Info auch von Chrome geliefert, wenn man auf das Schloss in der Adresszeile klickt und das Register Verbindung auswählt. Aber Hallo! Hier wird ein Go Daddy Zertifikat für chocolatey.org genannt! Ja was denn nun? GeoTrust oder Go Daddy? Des Rätsel Lösung nennt sich SNI und wird am Ende aufgelöst.

Tiefergehende Suche mittels Powershell
Wie kann man die Geschichte aber mittels Powershell besser in Griff bekommen? Da zu unterst immer irgendwo eine TCP-Verbindung aufgebaut werden muss, kann nur der direkte Aufruf über TCPClient etwas bringen.

Die einfachste Variante wäre nun:

$host = "chocolatey.org"
$port = 443
$conn = New-Object System.Net.Sockets.TcpClient ($host, $port)
$stream = New-Object System.Net.Security.SslStream($conn.GetStream())
$result=$stream.AuthenticateAsClient($host)
$conn.Close()

aber hier kommt nur wieder die Fehlermeldung wie oben bei der doppelten InnerException. Also was tun?

Der Konstruktor von SslStream kennt noch weitere Parameter. Unter anderem den RemoteCertificateValidationCallback Delegaten. http://msdn.microsoft.com/en-us/library/system.net.security.remotecertificatevalidationcallback(v=vs.110).aspx. Dieser wird üblicherweise benutzt, um bestimmte Fehlermeldungen in Verbindung mit Zertifikaten zu unterdrücken. Ab Powershell 2.0 ist dies ohne weiteres möglich, wie dieser Artikel hier schön beschreibt: http://www.nivot.org/blog/post/2009/07/18/PowerShell20RCWorking
WithNETCallbacksPart1Synchronous
. Der Callback kennt aber alle relevanten Informationen, so dass man diesen nun so nutzen kann:

$conn = New-Object System.Net.Sockets.TcpClient($host,$port)
$stream = New-Object System.Net.Security.SslStream($conn.GetStream(), $null, {
                    Write-Host "Sender: $($args[0])";
                    Write-Host "Certificate: $(($args[1]).gettype())";
                    Write-Host "CertificateChain: $($args[2])";
                    Write-Host "PolicyErrors: $($args[3])"; 
         })
$result = $stream.AuthenticateAsClient($host)
$conn.Close()

nun bekommt man als Ergebnis dies geliefert:

Sender: System.Net.Security.SslStream
Certificate: System.Security.Cryptography.X509Certificates.X509Certificate2
CertificateChain: System.Security.Cryptography.X509Certificates.X509Chain
PolicyErrors: RemoteCertificateNameMismatch

Also genau was auf MSDN als Parameter dokumentiert steht. Vor allem interessant ist nun die Aussage mit RemoteCertificateNameMismatch. Jetzt wird die Sache schon etwas klarer. Sollte chocolatey.org nicht im Zertifikat genannt sein?

Hier nun das Script welches die richtigen Infos ausgibt:

$conn = New-Object system.net.sockets.tcpclient($host, $port)
$stream = New-Object system.net.security.sslstream($conn.getstream(), $null, {
                    Write-Host $args[2].ChainElements[0].Certificate.Subject;
                    Write-Host "PolicyErrors: $($args[3])";
         })
$result = $stream.authenticateasclient("chocolatey.org")
$conn.Close()

Als Ausgabe erhält man:

CN=*.apphb.com, O=AppHarbor Inc, L=San Francisco, S=California, C=US, SERIALNUMBER=MyGg//QgdanmdPPqqfNR5JjsvbrKA/uJ
PolicyErrors: RemoteCertificateNameMismatch

Aha, nun wird es klarer. Wir wollen auf die Seite chocolatey.org bekommen aber ein Zertifikat vom Server für AppHarbor. Findet hier eine Attacke statt? Oh Gott, alle Schotten dicht!

Zusammenfassung
Ich wollte nur mal schnell Chocolatey installieren und bin dann wegen den Sicherheitsanforderungen von Chocolatey bei einer Attacke gelandet, wo mir irgendjemand falsche Zertifikate unterjubeln möchte. Oder ist doch alles ganz anders?

Aufklärung
Die Lösung des Dilemmas lautet SNI “Server Name Indication”. Ein schöner Artikel dazu findet man auf der deutschen Wikipedia unter http://de.wikipedia.org/wiki/Server_Name_Indication. Dort wird im Zusammenhang von SNI darauf hingewiesen, dass Windows XP kein Server Name Indication unterstützt. Warum ist dies wichtig? Weil Powershell mittels der Systembibliotheken von Windows XP seine HTTPS Verbindung aufbauen möchte und ebenso wie der IE8 Probleme bekommt. Hintergrund dafür ist, dass chocolatey.org bei HTTPS-Verbindungen auf SNI angewiesen ist, wie dieser Test zeigt: https://www.ssllabs.com/ssltest/analyze.html?d=chocolatey.org.

Dort ist dann zu lesen:

This site works only in browsers with SNI support.

Dies erklärt nun auch die unterschiedlichen Zertifikate. Denn IE8 auf Windows XP kann kein SNI, Chrome jedoch kann es, obwohl Windows XP zum Einsatz kommt. Der Grund dafür ist, dass Chrome seine eigene Crypto-Library mitbringt.

Beim Versuch also die Verbindung ohne SNI aufzubauen, landet man nicht auf dem gewünschten Server sondern bekommt ein allgemeineres Zertifikat des Hosters zurück. Dies erklärt nun den Punkt mit den unterschiedlichen Zertifikaten von GeoTrust und Go Daddy.

Man kann die Sache sehr schön nachverfolgen, wenn man Fiddler einsetzt. http://fiddler2.com/. Damit kann man, wenn der HTTPS-Mitschnitt aktiviert ist, sehr schön sehen, dass Powershell 2.0 diesen Aufruf generiert:

Version: 3.1 (TLS/1.0)

Extensions:
renegotiation_info 00
Ciphers:
[0004] SSL_RSA_WITH_RC4_128_MD5
[0005] SSL_RSA_WITH_RC4_128_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA
[0009] SSL_RSA_WITH_DES_SHA
[0064] TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
[0062] TLS_RSA_EXPORT1024_WITH_DES_SHA
[0003] SSL_RSA_EXPORT_WITH_RC4_40_MD5
[0006] SSL_RSA_EXPORT_WITH_RC2_40_MD5
[0013] SSL_DHE_DSS_WITH_3DES_EDE_SHA
[0012] SSL_DHE_DSS_WITH_DES_SHA
[0063] TLS_DHE_DSS_EXPORT1024_WITH_DES_SHA

Compression:
[00] NO_COMPRESSION

Während Chrome dies zustande bringt:

Version: 3.1 (TLS/1.0)

Extensions:
 server_name chocolatey.org
renegotiation_info 00
elliptic_curves secp256r1 [0x17], secp384r1 [0x18], secp521r1 [0x19]
ec_point_formats uncompressed [0x0]
SessionTicket TLS empty
NextProtocolNegotiation empty
ALPN  spdy/2; spdy/3; spdy/3.1; http/1.1;
channel_id empty
status_request 01 00 00 00 00
Ciphers:
[C02F] TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
[009E] TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
[009C] TLS_RSA_WITH_AES_128_GCM_SHA256
[C014] TLS1_CK_ECDHE_RSA_WITH_AES_256_CBC_SHA
[0039] TLS_DHE_RSA_WITH_AES_256_SHA
[0035] TLS_RSA_AES_256_SHA
[C011] TLS_ECDHE_RSA_WITH_RC4_128_SHA
[C013] TLS1_CK_ECDHE_RSA_WITH_AES_128_CBC_SHA
[0033] TLS_DHE_RSA_WITH_AES_128_SHA
[0032] TLS_DHE_DSS_WITH_AES_128_SHA
[0005] SSL_RSA_WITH_RC4_128_SHA
[0004] SSL_RSA_WITH_RC4_128_MD5
[002F] TLS_RSA_AES_128_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA

Compression:
[00] NO_COMPRESSION

Der Extensions-Eintrag server_name chocolatey.org ist genau der Punkt, welcher beim Powershell-Aufruf fehlt und die Sache zum Scheitern bringt. Gleichwohl auch Chrome innerhalb von Fiddler Probleme mit dem Aufruf bekommt, denn Fiddler2 basiert auf .Net Framework 2.0 und damit ist der weitere Fortgang zum Scheitern verurteilt und man bekommt am Ende nicht das Go Daddy Zertifikat sondern wieder das falsche GeoTrust Zertifikat.

Übrigens geht genau dieser Artikel auf das aktuelle Problem ein und bestätigt nochmal alles: https://groups.google.com/forum/#!searchin/chocolatey/geotrust$20/chocolatey/r9EdhJdPjWM/FavaGm07VtoJ

Zu guter Letzt noch die Bestätigung, dass Powershell 4.0 unter Windows 8.1 problemlos damit umgehen kann:

A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.

Version: 3.1 (TLS/1.0)

Extensions:
renegotiation_info 00
 server_name chocolatey.org
elliptic_curves secp256r1 [0x17], secp384r1 [0x18]
ec_point_formats uncompressed [0x0]
SessionTicket TLS empty
Ciphers:
[002F] TLS_RSA_AES_128_SHA
[0035] TLS_RSA_AES_256_SHA
[0005] SSL_RSA_WITH_RC4_128_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA
[C013] TLS1_CK_ECDHE_RSA_WITH_AES_128_CBC_SHA
[C014] TLS1_CK_ECDHE_RSA_WITH_AES_256_CBC_SHA
[C009] TLS1_CK_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
[C00A] TLS1_CK_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
[0032] TLS_DHE_DSS_WITH_AES_128_SHA
[0038] TLS_DHE_DSS_WITH_AES_256_SHA
[0013] SSL_DHE_DSS_WITH_3DES_EDE_SHA
[0004] SSL_RSA_WITH_RC4_128_MD5

Compression:
[00] NO_COMPRESSION

Also alles halb so wild, wenn man weiß, wie es zusammenhängt!

Offtopic: Gist und Github-Versuch

4 Januar 2014

Da die Skripte überhand nehmen und kleinere Codeschnipsel immer blöd aussehen, soll dieser Blogeintrag als Experiment dienen, ob ich evtl. in Zukunft die Sachen auf Github stelle und darauf verlinke.

Versuch 2:

Versuch 3, dieser soll auf die erste Revision des zweiten Eintrags verweisen:

Scheint zu klappen, hier noch der Link zu den Beschreibungen auf WordPress, wie die Links gesetzt werden müssen: http://en.support.wordpress.com/gist/


Follow

Erhalte jeden neuen Beitrag in deinen Posteingang.