unslug tr: move

4 files changed, 193 insertions, 0 deletions

diff --git a/files/tr/web/security/index.html b/files/tr/web/security/index.html
new file mode 100644
index 0000000000..1543d6a3db
--- /dev/null
+++ b/files/tr/web/security/index.html
@@ -0,0 +1,16 @@
+---
+title: Web güvenliği
+slug: Web/Güvenlik
+tags:
+  - Güvenlik
+  - Landing
+  - Web
+translation_of: Web/Security
+---
+<div class="summary">
+<p><span class="seoSummary">Websitenizin ya da uygulamanızın güvenliğini garantiye almak çok önemli. Küçük hatalar bile gizli verilerin sızmasına sebep olabilir ve dışarıdaki kötü niyetliler, verilerinizi çalmanın yollarını arıyorlar. Bu makaleler kodunuzu daha güvenli hale getirmeniz için size yardımcı olabilir.</span></p>
+</div>
+
+<p>{{LandingPageListSubpages}}</p>
+
+<p>{{QuickLinksWithSubpages}}</p>
diff --git a/files/tr/web/security/mixed_content/index.html b/files/tr/web/security/mixed_content/index.html
new file mode 100644
index 0000000000..2576d1c4bf
--- /dev/null
+++ b/files/tr/web/security/mixed_content/index.html
@@ -0,0 +1,44 @@
+---
+title: Mixed Content
+slug: Security/MixedContent
+translation_of: Web/Security/Mixed_content
+---
+<p>When a user visits a page served over HTTPS, their connection with the web server is encrypted with SSL and hence safeguarded from sniffers and man-in-the-middle attacks.</p>
+<p>If the HTTPS page includes content retrieved through regular, cleartext HTTP, then the connection is only partially encrypted: the unencrypted content is accessible to sniffers and can be modified by man-in-the-middle attackers, and therefore the connection is not safeguarded anymore. When a webpage exhibits this behavior, it is called a <em>mixed content</em> page.</p>
+<h2 id="Web_Console">Web Console</h2>
+<p>Starting in Firefox 16, the Web Console displays a mixed content warning message when a page on your website has this issue. The mixed content resource that was loaded via HTTP will show up in red, along with the text "mixed content" which will link to this page.</p>
+<p><a class="internal" href="/files/3794/mixed_content_webconsole.jpg"><img alt="Screen shot of the web console displaying a mixed content warning." src="/files/3794/mixed_content_webconsole.jpg" style="width: 700px; border-width: 1px; border-style: solid; height: 116px;"></a></p>
+<p>To fix this error, requests to HTTP content should be removed and replaced with content served over HTTPS. Some common examples of mixed content include JavaScript files, stylesheets, images, videos, and other media.</p>
+<p>Starting in Firefox 23, mixed active content is blocked by default (and mixed display content can be blocked by setting a preference). To make it easier for web developers to find mixed content errors, all blocked mixed content requests are logged to the Security pane of the Web Console.</p>
+<p><a href="/files/5261/blocked-mixed-content-errors.png"><img alt="A screenshot of blocked mixed content errors in the Security Pane of the Web Console" src="https://mdn.mozillademos.org/files/5261/blocked-mixed-content-errors.png" style="width: 725px; height: 107px;"></a></p>
+<h2 id="Types_of_Mixed_Content">Types of Mixed Content</h2>
+<p>There are two categories for mixed content: <strong>Mixed Passive/Display Content</strong> and <strong>Mixed Active Content</strong>. The difference lies in the threat level of the worst case scenario if content is rewritten as part of a Man-In-The-Middle attack. In the case of passive content, the threat is low (webpage appears broken or with misleading content). In the case of active content, the threat can lead to phishing, sensitive data disclosure, redirection to malicious sites, etc.</p>
+<h3 id="Mixed_passivedisplay_content">Mixed passive/display content</h3>
+<p>Mixed Passive/Display Content is content served over HTTP that is included in an HTTPS webpage, but that cannot alter other portions of the webpage. For example, an attacker could replace an image served over HTTP with an inappropriate image or message to the user. The attacker could also infer information about the user's activities by watching which images are served to the user; often images are only served on a specific page within a website. If the attacker observes HTTP requests to certain images, he could determine which webpage the user is visiting.</p>
+<h4 id="Passive_content_list">Passive content list</h4>
+<p>This section lists all types of HTTP requests which are considered passive content:</p>
+<ul>
+ <li><a href="/en-US/docs/Web/HTML/Element/audio" title="/en-US/docs/Web/HTML/Element/audio">&lt;audio&gt;</a> (<code>src</code> attribute)</li>
+ <li><a href="/en-US/docs/Web/HTML/Element/Img" title="/en-US/docs/Web/HTML/Element/Img">&lt;img&gt;</a> (<code>src</code> attribute)</li>
+ <li><a href="/en-US/docs/Web/HTML/Element/video" title="/en-US/docs/Web/HTML/Element/Img">&lt;video&gt;</a> (<code>src</code> attribute)</li>
+ <li><a href="/en-US/docs/Web/HTML/Element/object" title="/en-US/docs/Web/HTML/Element/object">&lt;object&gt;</a> subresources (when an &lt;object&gt; performs HTTP requests)</li>
+</ul>
+<h3 id="Mixed_active_content">Mixed active content</h3>
+<p>Mixed Active Content is content that has access to all or parts of the Document Object Model of the HTTPS page. This type of mixed content can alter the behavior of the HTTPS page and potentially steal sensitive data from the user. Hence, in addition to the risks described for Mixed Display Content above, Mixed Active Content is vulnerable to a few other attack vectors.</p>
+<p>In the Mixed Active Content case, a man-in-the-middle attacker can intercept the request for the HTTP content. The attacker can also rewrite the response to include malicious JavaScript code. Malicious active content can steal the user's credentials, acquire sensitive data about the user, or attempt to install malware on the user's system (by leveraging vulnerabilities in the browser or its plugins, for example).</p>
+<p>The risk involved with mixed content does depend on the type of website the user is visiting and how sensitive the data exposed to that site may be. The webpage may have public data visible to the world or private data visible only when authenticated. If the webpage is public and has no sensitive data about the user, using Mixed Active Content still provides the attacker with the opportunity to redirect the user to other HTTP pages and steal HTTP cookies from those sites.</p>
+<h4 id="Active_content_list">Active content list</h4>
+<p>This section lists some types of HTTP requests which are considered active content:</p>
+<ul>
+ <li><a href="/en-US/docs/Web/HTML/Element/script" title="/en-US/docs/Web/HTML/Element/script">&lt;script&gt;</a> (<code>src</code> attribute)</li>
+ <li><a href="/en-US/docs/Web/HTML/Element/link" title="/en-US/docs/Web/HTML/Element/link">&lt;link&gt;</a> (<code>href</code> attribute) (this includes CSS stylesheets)</li>
+ <li><a href="/en-US/docs/Web/API/XMLHttpRequest" title="/en-US/docs/Web/API/XMLHttpRequest">XMLHttpRequest</a> object requests</li>
+ <li><a href="/en-US/docs/Web/HTML/Element/iframe" title="/en-US/docs/Web/HTML/Element/iframe">&lt;iframe&gt;</a> (<code>src</code> attributes)</li>
+ <li>All cases in CSS where a <a href="http://www.w3.org/TR/css3-values/#urls" title="http://www.w3.org/TR/css3-values/#urls">url</a> value is used (<a href="/en-US/docs/Web/CSS/@font-face" title="/en-US/docs/Web/CSS/@font-face">@font-face</a>, <a href="/en-US/docs/Web/CSS/cursor" title="/en-US/docs/Web/CSS/cursor">cursor</a>, <a href="/en-US/docs/Web/CSS/background-image" title="/en-US/docs/Web/CSS/background-image">background-image</a>, etc.)</li>
+ <li><a href="/en-US/docs/Web/HTML/Element/object" title="/en-US/docs/Web/HTML/Element/object">&lt;object&gt;</a> (<code>data</code> attribute)</li>
+</ul>
+<h2 id="See_also">See also</h2>
+<div class="warning">
+ <p><a href="/en-US/docs/Security/MixedContent/fix_website_with_mixed_content">How to fix a website with blocked mixed content</a></p>
+</div>
+<p> </p>
diff --git a/files/tr/web/security/transport_layer_security/index.html b/files/tr/web/security/transport_layer_security/index.html
new file mode 100644
index 0000000000..5ba269b7cc
--- /dev/null
+++ b/files/tr/web/security/transport_layer_security/index.html
@@ -0,0 +1,115 @@
+---
+title: Transport Layer Security
+slug: Web/Güvenlik/Transport_Layer_Security
+translation_of: Web/Security/Transport_Layer_Security
+---
+<p><span class="seoSummary"><font><font>Aktarım Katmanı Güvenliği (TLS) kullanan herhangi bir bağlantının güvenliği büyük ölçüde seçilen şifre paketlerine ve seçilen güvenlik parametrelerine bağlıdır. </font><font>Bu makalenin amacı, istemci ve sunucu arasındaki gizlilik ve bütünlük iletişimini sağlamak için bu kararları almanıza yardımcı olmaktır. </font></font></span><font><font>Mozilla Operasyon Güvenliği (OpSec) ekibi </font><font>, sunucular için referans yapılandırmaları olan </font></font><a href="https://wiki.mozilla.org/Security/Server_Side_TLS"><font><font>bir wiki girişi tutar</font></font></a><font><font> .</font></font></p>
+
+<p class="summary"><font><font>Aktarım Katmanı Güvenliği (TLS) protokolü, iki ağa bağlı uygulamanın veya cihazın özel ve sağlam bir şekilde bilgi alışverişi yapmalarını sağlayan standarttır. </font><font>TLS kullanan uygulamalar, verilerin güvenliği ve güvenilirliği üzerinde önemli bir etkisi olabilecek güvenlik parametrelerini seçebilir. </font><font>Bu makale, TLS'ye ve içeriğinizi güvenceye alırken vermeniz gereken kararlara genel bir bakış sunmaktadır.</font></font></p>
+
+<h2 id="Tarih"><font><font>Tarih</font></font></h2>
+
+<p><font><font>HTTPS tanıtıldığında, Netscape tarafından sunulan bir teknoloji olan Güvenli Yuva Katmanı (SSL) 2.0'a dayanıyordu. </font><font>Kısa bir süre sonra SSL 3.0'a güncellendi ve kullanımı genişledikçe, tüm web tarayıcıları ve sunucular arasında birlikte çalışabilirliği sağlamak için ortak, standart bir şifreleme teknolojisinin belirtilmesi gerektiği anlaşıldı. </font></font><a href="https://www.ietf.org/"><font><font>Internet Engineering Task Force</font></font></a><font><font> (IETF) 'de TLS 1.0 belirtilmiş {{RFC (2246)}} Ocak 1999 yılında TLS mevcut sürümü olan 1.3 ({{RFC (8446)}}).</font></font></p>
+
+<div class="note">
+<p>Despite the fact that the web now uses TLS for encryption, many people still refer to it as "SSL" out of habit.</p>
+</div>
+
+<p>Although TLS can be used on top of any low-level transport protocol, the original goal of the protocol was to encrypt HTTP traffic. HTTP encrypted using TLS is commonly referred to as {{Glossary("HTTPS")}}. TLS-encrypted web traffic is by convention exchanged on port 443 by default, while unencrypted HTTP uses port 80 by default. HTTPS remains an important use case for TLS.</p>
+
+<h2 id="HTTP_over_TLS">HTTP over TLS</h2>
+
+<p>TLS provides three primary services that help ensure the safety and security of data exchanged with it:</p>
+
+<dl>
+ <dt>Authentication</dt>
+ <dd>Authentication lets each party to the communication verify that the other party is who they claim to be.</dd>
+ <dt>Encryption</dt>
+ <dd>Data is encrypted while being transmitted between the user agent and the server, in order to prevent it from being read and interpreted by unauthorized parties.</dd>
+ <dt>Integrity</dt>
+ <dd>TLS ensures that between encrypting, transmitting, and decrypting the data, no information is lost, damaged, tampered with, or falsified.</dd>
+</dl>
+
+<p>A TLS connection starts with a handshake phase where a client and server agree on a shared secret and important parameters, like cipher suites, are negotiated. Once parameters and a data exchange mode where application data, such HTTP, is exchanged.</p>
+
+<h3 id="Cipher_suites">Cipher suites</h3>
+
+<p>The primary parameters that the TLS handshake negotiates is a {{interwiki("wikipedia", "cipher suite")}}.</p>
+
+<p>In TLS 1.2 and earlier, the negotiated cipher suite includes a set of cryptographic algorithms that together provide the negotiation of the shared secret, the means by which a server is authenticated, and the method that will be used to encrypt data.</p>
+
+<p>The cipher suite in TLS 1.3 primarily governs the encryption of data, separate negotiation methods are used for key agreement and authentication.</p>
+
+<p>Different software might use different names for the same cipher suites. For instance, the names used in OpenSSL and GnuTLS differ from those in the TLS standards. The <a href="https://wiki.mozilla.org/Security/Server_Side_TLS#Cipher_names_correspondence_table">cipher names correspondence table</a> on the Mozilla OpSec team's article on TLS configurations lists these names as well as information about compatibility and security levels.</p>
+
+<h3 id="Configuring_your_server">Configuring your server</h3>
+
+<p>Correctly configuring your server is crucial. In general, you should try to limit cipher support to the newest ciphers possible which are compatible with the browsers you want to be able to connect to your site. The <a href="https://wiki.mozilla.org/Security/Server_Side_TLS">Mozilla OpSec guide to TLS configurations</a> provides more information on recommended configurations.</p>
+
+<p>To assist you in configuring your site, Mozilla provides a helpful <a href="https://mozilla.github.io/server-side-tls/ssl-config-generator/">TLS configuration generator</a> that will generate configuration files for the following Web servers:</p>
+
+<ul>
+ <li>Apache</li>
+ <li>Nginx</li>
+ <li>Lighttpd</li>
+ <li>HAProxy</li>
+ <li>Amazon Web Services CloudFormation Elastic Load Balancer</li>
+</ul>
+
+<p>Using the <a href="https://mozilla.github.io/server-side-tls/ssl-config-generator/">configurator</a> is a recommended way to create the configuration to meet your needs; then copy and paste it into the appropriate file on your server and restart the server to pick up the changes. The configuration file may need some adjustments to include custom settings, so be sure to review the generated configuration before using it; installing the configuration file without ensuring any references to domain names and the like are correct will result in a server that just doesn't work.</p>
+
+<h2 id="TLS_1.3">TLS 1.3</h2>
+
+<p>{{RFC("8446", "TLS 1.3")}} is a major revision to TLS. TLS 1.3 includes numerous changes that improve security and performance. The goals of TLS 1.3 are:</p>
+
+<ul>
+ <li>Remove unused and unsafe features of TLS 1.2.</li>
+ <li>Include strong security analysis in the design.</li>
+ <li>Improve privacy by encrypting more of the protocol.</li>
+ <li>Reduce the time needed to complete a handshake.</li>
+</ul>
+
+<p>TLS 1.3 changes much of the protocol fundamentals, but preserves almost all of the basic capabilities as previous versions of TLS. For the web, TLS 1.3 can be enabled without affecting compatibility with some rare exceptions (see below).</p>
+
+<p>The major changes in TLS 1.3 are:</p>
+
+<ul>
+ <li>The TLS 1.3 handshake completes in one round trip in most cases, reducing handshake latency.</li>
+ <li>A server can enable a 0-RTT (zero round trip time) handshake. Clients that reconnect to the server can send requests immediately, eliminating the latency of the TLS handshake entirely. Though the performance gains from 0-RTT can be significant, they come with some risk of replay attack, so some care is needed before enabling this feature.</li>
+ <li>TLS 1.3 supports forward-secure modes only, unless the connection is resumed or it uses a pre-shared key.</li>
+ <li>TLS 1.3 defines a new set of cipher suites that are exclusive to TLS 1.3. These cipher suites all use modern Authenticated Encryption with Associated Data (AEAD) algorithms.</li>
+ <li>The TLS 1.3 handshake is encrypted, except for the messages that are necessary to establish a shared secret. In particular, this means that server and client certificates are encrypted. Note however that the server identity (the server_name or SNI extension) that a client sends to the server is not encrypted.</li>
+ <li>Numerous mechanisms have been disabled: renegotiation, generic data compression, {{interwiki("wikipedia", "Digital Signature Algorithm")}} (DSA) certificates, static RSA key exchange, and key exchange with custom Diffie-Hellman (DH) groups.</li>
+</ul>
+
+<p>Implementations of draft versions of TLS 1.3 are available. TLS 1.3 is enabled in some browsers, including the 0-RTT mode. Web servers that enable TLS 1.3 might need to adjust configuration to allow TLS 1.3 to operate successfully.</p>
+
+<p>TLS 1.3 adds just one significant new use case. The 0-RTT handshake can provide significant performance gains for latency sensitive applications, like the web. Enabling 0-RTT requires additional steps, both to ensure successful deployment and to manage the risks of replay attacks.</p>
+
+<p>The removal of renegotiation in TLS 1.3 might affect some web servers that rely on client authentication using certificates. Some web servers use renegotiation to either ensure that client certificates are encrypted, or to request client certificates only when certain resources are requested. For the privacy of client certificates, the encryption of the TLS 1.3 handshake ensures that client certificates are encrypted; however this might require some software changes. Reactive client authentication using certificates is supported by TLS 1.3 but not widely implemented. Alternative mechanisms are in the process of being developed, which will also support HTTP/2.</p>
+
+<h2 id="Retiring_old_TLS_versions">Retiring old TLS versions</h2>
+
+<p><font><font>Daha modern, daha güvenli bir web üzerinde çalışmanıza yardımcı olmak için, TLS 1.0 ve 1.1 desteği, 201'in ikinci çeyreğindeki tüm büyük tarayıcılardan kaldırılacaktır </font></font><strong> </strong><font><font>. Web sunucunuzun, ileride TLS 1.2 veya 1.3'ü desteklediğinden emin olmanız gerekir.</font></font></p>
+
+<p><font><font>74 sürümünden itibaren Firefox </font><font>, eski TLS sürümlerini ({{bug (1606734)}}) kullanan sunuculara bağlanırken </font></font><a href="https://support.mozilla.org/en-US/kb/secure-connection-failed-firefox-did-not-connect"><font><font>Güvenli Bağlantı Başarısız</font></font></a><font><font> hatası döndürecektir.</font></font></p>
+
+<h2 id="TLS_el_sıkışma_zaman_aşımı_değerleri"><font><font>TLS el sıkışma zaman aşımı değerleri</font></font></h2>
+
+<p><font><font>TLS anlaşması bir sebepten dolayı yavaşlamaya veya yanıt vermemeye başlarsa, kullanıcının deneyimi önemli ölçüde etkilenebilir. </font><font>Bu sorunu hafifletmek için, modern tarayıcılar el sıkışma zaman aşımlarını uygulamıştır:</font></font></p>
+
+<ul>
+ <li><font><font>Sürüm 58'den bu yana, Firefox varsayılan değer olan 30 saniyelik bir TLS el sıkışma zaman aşımı uygular. </font><font>Zaman aşımı değeri </font></font><code>network.http.tls-handshake-timeout</code><font><font>pref: about: config düzenlenerek değiştirilebilir.</font></font></li>
+</ul>
+
+<h2 id="Ayrıca_bakınız"><font><font>Ayrıca bakınız</font></font></h2>
+
+<ul>
+ <li><a href="https://ssl-config.mozilla.org"><font><font>Mozilla SSL Yapılandırma Jeneratör</font></font></a><font><font> ve </font></font><a href="https://cipherli.st/"><font><font>Cipherli.st</font></font></a><font><font> sitenizi güven altına almak için sunucu için yapılandırma dosyaları oluşturulmasına yardımcı olabilir.</font></font></li>
+ <li><font><font>Mozilla Operasyon Güvenliği (OpSec) ekibi </font></font><a href="https://wiki.mozilla.org/Security/Server_Side_TLS"><font><font>referans TLS yapılandırmalarına</font></font></a><font><font> sahip bir wiki sayfası tutar </font><font>.</font></font></li>
+ <li><a href="https://observatory.mozilla.org/"><font><font>Mozilla Gözlemevi</font></font></a><font><font> , </font></font><a href="https://www.ssllabs.com/ssltest/"><font><font>SSL Labs</font></font></a><font><font> ve </font></font><a href="https://github.com/mozilla/cipherscan"><font><font>Cipherscan</font></font></a><font><font> , bir siteyi TLS yapılandırmasının ne kadar güvenli olduğunu görmek için test etmenize yardımcı olabilir.</font></font></li>
+ <li><a href="/en-US/docs/Web/Security/Secure_Contexts"><font><font>Güvenli Bağlamlar</font></font></a></li>
+ <li><a href="/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security"><font><font>Strict-Transport-Security</font></font></a><font><font>  HTTP üstbilgisi</font></font></li>
+</ul>
+
+<p><font><font>{{QuickLinksWithSubpages ( "/ tr / docs / Web / Güvenlik")}}</font></font></p>
diff --git a/files/tr/web/security/weak_signature_algorithm/index.html b/files/tr/web/security/weak_signature_algorithm/index.html
new file mode 100644
index 0000000000..c80645ff36
--- /dev/null
+++ b/files/tr/web/security/weak_signature_algorithm/index.html
@@ -0,0 +1,18 @@
+---
+title: Zayıf İmza Algoritması
+slug: Security/Zatıf_İmza_Algoritması
+tags:
+  - Kılavuz Güvenlik Algoritmalar
+translation_of: Web/Security/Weak_Signature_Algorithm
+---
+<h3 id="İmza_Algoritması_Neden_Önemli">İmza Algoritması Neden Önemli</h3>
+
+<p>Sertifika imzalamada kullanılan imza algoritmaları sertifikaların güvenliğinin kritik bir elemanıdır. İmza algoritmalarındak zayıflıklar saldırganları sahte sertifikalar üretmelerine yol açabilir. Yeni atak türlerini bulunması ve teknolojideki gelişmeler imzalara karşı yapılan saldırılarda başarılı olmayı daha fazla mümkün hale getirmiştir. Bu sebeplerden eski algoritmaların kullanımından vazgeçilmekte ve nihayetinde destek kaldırılmaktadır.</p>
+
+<h3 id="SHA-1">SHA-1</h3>
+
+<p>SHA-1 tabanlı imzalar sertifikalarda, bu yazı zamanında, yaygın olarak kullanılmaktadır. Ancak, SHA-1 eskimekte olan bir algoritmadır ve kullanımından vazgeçilmelidir. Sertifika yenileme zamanları geldiğinde daha güçlü bir imza algoritmasının kullanıldığındna emin olunmalıdır. Bu konu hakkında daha detaylı bilgiyi <a href="https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/">Mozilla Security Blog post</a> gönderisinde okuyabilirsiniz. (İngilizce olabilir)</p>
+
+<h3 id="MD5">MD5</h3>
+
+<p>MD5 tabanlı imzalara destek 2012 yılı başlarında kaldırılmıştır.</p>