mkcertを利用してローカルのNext.js開発環境にHTTPSアクセスができるようにしてみた | DevelopersIO
こんにちは！DA(データアナリティクス)事業本部 サービスソリューション部の大高です。 Next.jsのアプリケーション開発をしている際に、HTTPSでアクセスしたいことはないでしょうか？私はあります。 ということで、mkcertを利用してローカルのNext.js開発環境にHTTPSアクセスができるようにしてみました。 前提 OS環境としては、MacOSで検証を行っています。 mkcert について mkcertはローカル開発環境に信頼された証明書を作成できるツールです。 今回はこちらを利用して証明書を発行してみます。 インストール インストールはMacOSの場合brewコマンドで簡単にインストールすることができます。なお、MacOS以外についてもREADMEにインストール方法が記載されています。 % brew install mkcert ==> Fetching mkcert ==>
詳解 Reliable UDP - Speaker Deck
謎の伝送制御プロトコルRUDPの詳細について解説します これは2018年11月10日に行われた Kernel/VM/探検隊@北陸 part 4 での発表資料です サンプルコード: https://github.com/Fadis/rudp
アプリケーション内でhttpsによる外部APIを叩いているサーバのメモリ使用量が増加し続ける件について - s_tajima:TechBlog
問題 アプリケーション内でhttpsによる外部APIを叩いているサーバのメモリ使用量が増加し続ける件について調べた。 該当のサーバでは、以下のようにメモリの使用率が徐々に上昇していく。 また、アプリケーションのプロセス自体がメモリを消費しているわけではない状態。 原因 調査すると、このバグ仕様を踏んでいるのではないかと思われるページを見つけた。 https://bugzilla.redhat.com/show_bug.cgi?id=1044666 内容としては、curlを実行した際に /etc/pki/nssdb/以下の存在しないファイル(毎回違うパス)に対してaccessシステムコールが大量にコールされ、 negative dentry cacheが溜まっていき、メモリ使用量が圧迫されるというもの。 実際、この状況が起きているサーバを調べるとメモリ使用率のうち多くを占めているのはnega
DNS over HTTPSを使ってDNSレコードを外形監視 - LIVESENSE ENGINEER BLOG
こんにちは、インフラグループの水野です。 みなさん、DNSのレコードの監視を行っていますか？ DNSレコードの変更ミス等を検知することはもちろん、自分たちの運営しているサービスの名前解決がユーザ側でどのように見えているのかというのを確認することは大切です。 しかしながら、DNSレコードを外形監視してくれる監視ツールは数が少なく中々コレといったものがありません。 外部からの監視をしたいがためにパブリッククラウドに監視専用のインスタンスを建てるのももったいないです。 弊社ではメインの監視ツールとして Mackerel を利用していますが、MackerelにはURL外形監視はありますが、DNS外形監視はありません。 別途 pingdom のDNS外形監視を利用していましたが、pingdomではIPアドレスとのマッチしかできません。 IPアドレスもひとつしか登録できないため、ELBのようにIPアド
pixivのHTTP/2有効化の軌跡 - pixiv inside
@catatsuyです。普段はpixivの技術的な改善や広告周りを見ています。今回はHTTP/2の話を紹介します。 HTTPS化とHTTP/2について 以前紹介したようにpixivは2017/4/18にHTTPS化を完了していました。 pixivを常時HTTPS化するまでの道のり（前編） - pixiv inside pixivを常時HTTPS化するまでの道のり（後編） - pixiv inside 昨今ブラウザで使える新しい技術はHTTPSが必須要件とされることが多くなりました。その中の代表格がHTTP/2です。HTTP/2自体はHTTPSを要求していませんが、実際にはHTTPSでなければブラウザ側で有効にならないため必須です。 HTTP/2に対応するメリットは他の詳しい記事を参照して欲しいですが、ざっくり以下のメリットがあります。 HPACKという仕様でハフマン符号を使ったHTTPヘッ
HTTPS通信とプロキシサーバ（CONNECTメソッド） : ネットワークスペシャリスト - SE娘の剣 -
そうなんですか？じゃあ、SSL通信をすれば、プロキシによるセキュリティチェック、ウイルスチェックなどは無しということ？ 結構危険ですね。 最近の製品では、HTTPS通信であっても、きちんと中継する製品が多い。この仕組みを実現するには、プロキシサーバで、代理のサーバ証明書を提示する。場合によっては、PC側でブラウザによるセキュリティ警告がでる可能性がある。 詳しくはこの問題にチャレンジいただきたい。 一方, Lプロキシを利用したHTTPS通信では,ブラウザとLプロキシ間,及びLプロキシとWebサーバ間において,それぞれ独立の暗号化された通信路を確立する。Lプロキシは証明書1を受け取ると,ブラウザには転送せずに,自身で証明書1の検証を行う。次に, Lプロキシは認証局として証明書1と同じコモンネームのサーバ証明書(以下,証明書2という)を新たに作成し,ブラウザに送る。Lプロキシを利用した場
作って学ぶ 「Https Man in The Middle Proxy」 in Go - ( ꒪⌓꒪) ゆるよろ日記
ᕕ( ᐛ )ᕗ こんにちわ、しいたけです。 webのhttps化が推進される昨今ですね? https通信は経路上での通信内容が盗聴・改竄されるのを防ぐことができますが、開発用途でhttps通信の内容を確認したい場合が稀にあります。 そのような場合は mitmproxy などを導入すればよいのですが、せっかくなので実際にこのようなProxyをGoで実装してみて、 中間者攻撃(Man-in-The-Middle Attack)がどのような手法でhttps通信を盗聴・改竄するのか確かめてみました。 実際に書いたProxyのコードはこちらです yuroyoro/mitm_proxy_sample https proxy と HTTP CONNECT tunneling まず、通常のhttps Proxyの動作を確認してみましょう。 httpsでは、ProxyはクライアントからのCONNECTメソッ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Yahoo広告配信用 s.yimg.jp ドメインでのXSSの解説